The Status of Const

[Walter Bright]

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.