Curios, for constants you use 'const val', why not just const?

the Kotlin syntax for constants is

const val

. These are for values that are known at compile time, and are inlined into where they are used. This differs from

val

that assigns values at runtime.

Ben has a point, why not just

const

🤔 It's not like you could have a

const var

, so composability isn't a thing here and the chosen solution is longer which unfortunately reminds me of Java's

final var

.

const

should be left as a modifier to keep future uses open

My point is the val does not give you anything. const var would be nonsense. I'm curious why the people who created the syntax decided on it.

const fun

might have a future meaning

so why would you need

const x = 5

and ``const val x = 5`` in the language. My uneducated impression is that you could always reinterprete a runtime

const x = 5

(with the current

const val

semantics) to also have a comptime semantic without breaking any existing code because comptime doesn't exist yet.

presently, Kotlin constants (

const val

) are only evaluated at compile time and do not exist at runtime.

so? how is that different from something that would be denoted by only

const

in other languages?

Chris: that's not totally true, they still exist at runtime even though all static references are inlined, at least on JVM

@ephemient as far as I know,

comptime

values/functions in Zig are available at compile-time and runtime. I just got an idea, that might explain why

const val = 5

might be better idea than simply the keyword

const x = 5

.

const

is probably composable after all, not with

var

but with

fun

(possibly in the future)!?! I do prefer the idea of using

const val

and

const fun

over

const

and

const fun

.