D has the nice notion of a transitively applied const keyword so you can pass some data into a method or class and know it will not be changed through that code. It seems that for some reason new JVM languages like Kotlin and Ceylon are rarely interested in such things, but const-correctness seems like a useful type system feature to have. Are there any plans?
1 Like
As C++ and D show, const is not that easy. We'd like to have something like it, but it's hard to implement in a useful way
1 Like
How do you mean? Is the D approach not useful?
Given the effort that it takes to make immutable objects in Java and generally control state, it’d be nice if Kotlin had some convenience features for this.
1 Like
D's approach is useful, but to make it work in Kotlin we'd need to know, for example, what's const in JDK and what's not. We are exploring the possible ways of knowing that, but it's not straightforward. Also, D's approach does not support lazy evaluation, caches of all sorts etc, that we think are crucial in application software.
BTW, note that const does not come alone, but together with immutable, which we also would like to have in Kotlin, and which needs some more careful design wrt Java libearies, memory model etc
Sorry for the necropost, but I was about to post a topic on this myself - immutable and const correctness. I have a list of mostly-non-vital organs I’d be willing to sell for this. Especially if it came with some kind of keyword/marker/whatever to use in a generic statement to indicate only immutable types are applicable. I’m sure that’s not a terribly common use case, but I know anything that a hash code - such as HashMap - for looking for an object borks if the hash code ever changes. If it’s an immutable object, you don’t have to worry about that, so if you declare something like HashMap<immutable K, V> you won’t be allowed to use a mutable key.
2 Likes