Const template

[Andrei Alexandrescu (See Website For Email)]

Dave wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Casts can break any design, so it's not phasing anyone off that they 
>> can break const. Besides, the fact that Const holds a pointer to the 
>> object as its first element is not something client code is allowed to 
>> rely on. This is a non-issue.
> 
> I wish Walter would have agreed with many of us that it (casts breaking 
> any design) is a "non-issue" for going ahead with a 'semantically 
> meaningful const' a year ago. I hope you can convince him!

My statement about design-breaking casts needs qualifying. Walter (and I 
entirely agree with him) dislikes the fact that C++ actually _legalizes_ 
const removal via a cast. Consider the following C++ code:

void Foo(const int & x)
{
   const_cast<int&>(x) = 0;
)

int main()
{
   int x = 1;
   Foo(x);
}

This is 100% legal C++ code with defined behavior; casting away const is 
ok if the initial data was not const. This feature kicks const straight 
in the proverbials.

A "design-breaking" cast is different: the language does not guarantee 
the behavior of code that uses it, and therefore can act under the 
assumption that it will not happen. This is key to introducing const in 
D in a manner that is useful to everybody.

>>> Both "user-space" and "compiler-space" const has been discussed at 
>>> length in the past, and Walter's response has always been 
>>> (paraphrasing) "D won't have const unless it is semantically 
>>> meaningful (100% enforceable) by the compiler", which will never 
>>> happen with a language like D.
>>
>> This statement must be understood in spirit. The spirit is, D 
>> shouldn't add a feature that fails spectacularly at providing a true 
>> guarantee, as C++ did. The design I suggested does without the actual 
>> feature.
>>
> 
> I completely agree with this sentiment. In earlier discussions, there 
> were designs that went even further, for example not being able to take 
> the address of or cast from a const parameter, etc.
> 
> But IMO that sentiment has been subjectively and unevenly applied to 
> different but often requested language requests over the years. 
> Unfortunately the earlier const suggestions were a case where the same 
> sentiment was not applied. IIRC, the majority of the "group" - many of 
> which had a large amount of experience writing libraries with D - 
> strongly favored a 'const' or 'readonly' even though the compiler could 
> not always guarantee they couldn't be modified.

It is then possible they were wrong, or that they didn't come with a 
reasonable design. Speaking of which (famous last words to come), I 
don't want to sound harsh, but if there is one thing that's worse than 
language design by committee, that's got to be language design by 
community. Having too many cooks in the kitchen dilutes vision, which is 
probably the single most important thing in a language design. The few 
places where Walter made populist decisions are eminently visible in the 
language design (ah, "length", gotta love that one), and many feature 
requests that have been aired on this newsgroup are in dire need of design.


Andrei