What are the obstacles for Scala having "const classes" a la Fantom?

Question

Fantom supports provably immutable classes. The advantages of the compiler knowing a class is immutable must be numerous, not the least of which would be guaranteed immutable messages passed between actors. Fantom's approach seems straightforward - what difficulties would it pose for Scala?

Answer 1

There's more interest on Scala side on tracking side effects, which is a much harder proposition, than simply immutability.

Immutability in itself isn't as relevant as referential transparency, and, as a matter of fact, some of Scala's immutable collections would not pass muster on an "proven immutable" test because, in fact, they are not. They are immutable as far as anyone can observer from the outside, but they have mutable fields for various purposes.

One such example is List's subclass :: (the class that makes up everything in a list but the empty list), in which the fields for head and tail are actually mutable. This is done that way so that a List can be composed efficiently in FIFO order -- see ListBuffer and its toList method.

Regardless, while it would be interesting to have a guarantee of immutability, such things are really more of a artifact of languages where mutability is the default. It doesn't come up as a practical concern when programming in Scala, in my experience.

Answer 2

While the approach may be straightforward,

1. its guarantees can be broken by reflection;
2. it requires quite a bit of effort, which the Scala team may think not worth it or not a priority.