Are there any cases where a

val

might be

const

but it is useful not to make it

const

?

const

means the value of the variable will be inlined everywhere it's used. So if you can foresee ever changing the value you should not make it

const

.

I don’t get the answer. `val`s can not change.

He means at compile time.

@diesieben07 but given that it can only be

const

if it is assigned a literal value and is either top-level, or a member of an object declaration, any change I would make to it would only happen in the context of recompiling anyway, which means the new value would be inlined wherever the const was used. Is there a case when using reflection, perhaps? Or some manner of hot module reloading?

If library B and C uses library A (which has a const defined). A changes its const's value and publishes update. C upgrades it's used version of A. (B does not). Application D uses libraries B and C. Library B would still have the old value of A's const inlined and C would have the new one.

Lovely explanation, thank you