Head Const

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 17 February 2016 at 11:56:29 UTC, Andrei 
Alexandrescu wrote:
> On 02/16/2016 09:53 PM, Walter Bright wrote:
>> Most of what people find frustrating about D's transitive
>> const/immutable is its very nature of not being sloppy and 
>> full of holes.
>
> I thought it was the constructors and postblit that are the 
> matter. (It may seem I'm on a snarky streak, but I do think 
> that's the remaining issue with immutable). -- Andrei

Yes, those are design problems with D's const that we really need 
to figure out how to fix, but they're not necessarily what people 
complain about. Many folks want to be able to do things like lazy 
initialization or caching or have a mutable reference count in a 
const/immutable object. The problems that usually come up 
basically boil down to folks wanting logical const rather than 
the compiler actually guaranteeing that data cannot be mutated 
via a const reference to that data without violating the type 
system. Lots of people basically want holes in const, because 
that's what C++ has, and not having holes in const prevents a 
number of potentially useful idioms (heck, you were trying to get 
around it with a container that you posted in the main newsgroup 
semi-recently and in RCString when you posted about it in 
dlang-study the other day).

We need to solve the constructor/postblit issues in order for D's 
const to really work like it's supposed to, but even if that 
problem were solved, the basic tenet of D's design for const - 
that it has no backdoors - is what really makes it so that many 
folks avoid const completely, whereas others use it but violate 
the type system by casting away const and mutating, not realizing 
that unlike C++, it's undefined behavior in D.

Regardless of whether Walter's (and thus D's) stance on const is 
the right one, it clearly doesn't jive with what a lot of folks 
(particularly those from C++) are looking for or expecting.

- Jonathan M Davis