const

[Walter Bright]

Oskar Linde wrote:
> Does the constancy have to be a part of the type?

Yes. Because generic code needs to be able to deconstruct a type and 
reconstitute it. That means the const has to travel with the components 
of the type.

> 1. Plain data types don't need the storage constancy to be a part of the 
> type.

Right, and that works fine until you try to do generic type 
manipulation. For example, if you use a template to convert a T* into a 
T[], you first strip the * off of T*, then add the []. If T was const, 
then your pointer to const correctly produces an array of const. But if 
const cannot be applied to a plain data type, then the const'ness will 
be lost.

> I have asked before but never gotten an answer: Can't this be 
> solved automatically by the compiler instead?

Couldn't find a way that worked.


> Now, what about the concepts of const/invariant? They have nothing to do 
> with the actual data, and only make sense in relation to a reference to 
> such data. Consider:
> 
> invariant(int)* a;
> 
> Here, a is actually not a pointer to an invariant int. It is a pointer
> that assumes the int it points to is "invariant". The difference is
> subtle but quite important. Likewise:
> 
> const(int)* b;
> 
> is not a pointer to a const int. It is a pointer through which the user 
> is disallowed to change the int. That doesn't mean that the int it
> points to is actually const.
> 
> the const(...)* and invariant(...)* part of the type declaration should 
> actually be considered a part of the pointer type. Not a part of the 
> target type.
> 
> So, const and invariant are type meta qualifiers, that carry assumptions 
> about the data. Those assumptions make sense in the context of 
> references, but not in declarations of plain data variables. For 
> example, given:
> 
> const int x = 5;
> 
> D 2.010 assigns the type of &x const(int)*. But I would consider that 
> wrong. The type should be invariant(int)*, since x is storage constant. 
> The actual type of x could actually just as well be int (observation 1). 
> Local (storage) constancy doesn't need to be a part of the type.

You're right, but again, the problem comes up when you're writing 
templates that deconstruct and construct types. Taking these semantic 
shortcuts in the compiler cause havoc with templates. That's why we 
finally gave up on such and went to a consistent, pedantic approach.


> So, without any loss of power, transitivity or anything else, one can 
> simplify the language and make the constancy of plain data compatible 
> between D2 and D1.

We tried, it almost works but there are enough corner cases to make it 
just not work. Const is not the way it is now in D for lack of trying to 
make all these cases work - and trying to make them work was what led to 
the previous two (failed) const regimes. We spent hundreds of hours 
working through the issues.