Const template

[Walter Bright]

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

My objections to the C++ const are:

1) there are *legal* ways to subvert it, meaning it is useless as a 
semantic aid and useless to the optimizer/code generator
2) it confuses a type modifier with a storage class (exhibiting muddled 
special case behaviors)
3) it's ugly and litters declarations
4) the use of overloading based on const is a workaround to another 
design flaw in C++

I've stated that I would put a const in if we could find a design 
without those shortcomings. I also believe D is better off with no const 
at all rather than a half-assed one.

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

The idea is that if the compiler did put all the const data into 
readonly memory, that it would not change the behavior of a conforming 
program. In other words, it would be undefined behavior to deliberately 
subvert the const via casting, inline assembler, or pointer manipulation.

This is quite different from C++, where (as Andrei pointed out) it is 
legal, defined behavior to subvert const.

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

Designs and proposals are posted every day in this n.g. It's simply not 
possible to implement them all, or even give coherent replies to them 
all. But these n.g. discussions are valuable - the lazy parameter and 
scope guard designs were significantly improved as a direct result. The 
way import now works is a direct result of the n.g., for just 3 of many 
examples.