Const template

[Andrei Alexandrescu (See Website For Email)]

Walter Bright wrote:
> 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)

Let me point out that D's current handling of the storage classes is 
broken. D defines the 'inout' and 'out' storage classes which are 
undetectable for templates and break any template code that needs to 
deal with them. (Why in the world was 'out' ever needed? Probably the 
"working with IDL" assumption should be revisited.) Then, to add insult 
to injury, D defines the 'lazy' storage class that changes the access 
syntax (something that a storage class is not supposed to do), does not 
allow assignment from the same type (although it should), and again 
can't work with any template code.

> 3) it's ugly and litters declarations
> 4) the use of overloading based on const is a workaround to another 
> design flaw in C++

But right now D is worse off than C++ because in D you can't overload on 
inout (or detect it in other ways) except for a much contorted way that 
I recall I've seen in a post around here. So where C++ is simply 
verbose, D is knee-deep in the mud.

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

Yup. We need a full-assed one :o).

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

I don't know much about import, am in favor of scope guard's improved 
syntax (compared to the one I proposed), and I'm positive that lazy is 
the epitome of bad language design and should go away. The article:

http://www.digitalmars.com/d/lazy-evaluation.html

proudly acknowledges the post:

http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=41633

which doesn't make any sense of anything, confuses lazy/delegates with 
expression templates, and fails to provide both a solid argument for 
'lazy' and the shade of a valid design for it. The net result is:

- lazy is a full-fledged type constructor coming in the disguise of a 
storage class;

- lazy cannot be assigned even from same type, nor from a delegate, 
which reduces templates' ability to manipulate lazy and non-lazy stuff 
uniformly;

- templates are powerless with lazy, as they are with any other storage 
class; they are doubly powerless with lazy because they now need to deal 
with the modified access syntax.

I believe that populism in language design is not good.


Andrei