Jonathan M Davis wrote:
That is, unfortunately, a very good point. It's still seriously limiting, however. What it means is that there is going to be code out there (and possibly a lot of it) which _should_ be const but can't be.
I presume you're talking about "logical constness", for data structures that lazily evaluate or memoize their contents. I think this is a higher level abstraction than what const should be. It is like asking the type system to also distinguish between things like validated data and non-validated data.
It can be done, but it's currently beyond the scope of D's type system.
I confess that the more that I deal with immutable, the less I like it. const doesn't complicate things all that much and brings a lot of improvements. immutable complicates things quite a lot more and does not bring the same level of improvements to the table. However, it does help with multi-threaded apps which _is_ very important, and increasingly so, so it's probably better to have it than not. Still, it can be very frustrating. However, if there's a better way to do it, it'll likely be found with either a future version of D or a language which replaces D. There's a shortage of languages which have tried to mix const, mutable, and immutable together (D may be the only one actually), so there isn't much experience to base improvements on. And is usually the case, it's much easier to see the problems than their solutions.
There are many languages which support immutable - but it's hidden away in how they handle strings. For example, Perl has immutable strings.
The great advantage to immutability (aside from threading) is that you can treat a reference type as if it were a value type. This is why so many languages treat strings that way. With D's immutability in the type system, rather than special cased for strings, is you can bring that advantage to any of your user defined types.
