Const template

[Andrei Alexandrescu (See Website For Email)]

Tom S wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> 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,
> 
> Well, thanks for the attack, but it was an attempt to suggest a fix, as 
> the introduction of lazy evaluation broke existing code in a non-trivial 
> way.

You are not being attacked. Not even the post was attacked, but rather 
the haste with which a feature was implemented before a good design was 
being put forth.

[snip]
>> I believe that populism in language design is not good.
> 
> Listening to ideas and opinions from language users is a bad idea ? 
> Taking my post as an example, it was merely a compromise between the 
> screams of other D users and Walter's opinion. Had Walter ignored it, 
> the net result would be more confusion and irritation, along with a 
> strange rule of implicitly converting lazy expressions to delegates.

I think the current state of affairs is stranger than that implicit 
conversion rule. It will now take additional effort, and a certain 
amount of code breakage, to fix the design. In an ideal world, things 
would have gone through a more critical review before just making it 
into the language.

> This said, I don't think that the way lazy expressions are currently 
> implemented is even close to being optimal. out/inout could be changed 
> too, as out/inout params can be detected, but one cannot realistically 
> instantiate a function template with mixed in/out/inout params.

There is an ongoing idea of binding an expression to an alias, which 
probably will do a good job (better opportunities for inlining). As far 
as in/out/inout (and actually lazy/scope/const) go, Walter will take up 
to fixing the issue and has a design for distinguishing among them 
properly. All of these keywords will be raised to the status of type 
constructors, and the constructed types will have well-defined 
semantics. Combinations (e.g. lazy inout) will be allowed when the 
semantics allow it.

Anyhow, speaking of a more critical review, the current intended rules 
for lazy are:

* lazy is a type constructor (takes a type, returns a type)

* sizeof(lazy T) = sizeof(T delegate())

* initialization = expression of type T or expression of type lazy T

* assignment: expression of type lazy T

* access: every access invokes the delegate. No trailing parens.

* deduced automatically: never

* can occur in: (a) function argument list; (b) function return type; 
(c) all lvalue contexts (namespace-level, local, struct member, class 
member, array, hash)

One irregularity is that assignment from an expression of type T is not 
accepted, amid fears that this would cause confusion. Probably we could 
drop this irregularity.

Looking forward to feedback!


Andrei