Const template

[Dave]

Andrei Alexandrescu (See Website For Email) wrote:
> 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.
> 

I think the general understanding was that D const would not be C++'s const (with all of the warts 
like the one you pointed out), but _also_ would need to go further and be a "guarantee".

> 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.
> 

IIRC, Walter has made mention of const truly being 'readonly', even to the point of wishing for some 
way to enforce it with hardware or OS support. It should be in the archives somewhere. Like I said I 
hope he can be or already is convinced otherwise since hardware / OS support isn't available, at 
least on the most popular platforms.

>>>> 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.
> 

I should qualify "designs".. There were a few posts that may be considered full-fledged "designs", 
but most of them were just ideas put forward on const and how to make it generally usable. The 
problem always came to be that none of them could guarantee what was understood as a prerequisite 
from Walter - truly read-only.

> 
> Andrei