What are the obstacles for Scala having "const classes" a la Fantom?
scala
Solution
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.
Problem
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?