Const template

[Andrei Alexandrescu (See Website For Email)]

Bill Baxter wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
> 
>> Anyhow, speaking of a more critical review, the current intended rules 
>> for lazy are:
> 
> Does the lack of syntax mean that the syntax has yet to be decided upon?

The syntax was described and is the same as using regular lvalues.

>> * deduced automatically: never
> 
> What does this mean, exactly?  Is it speaking of a template parameter? 
> Or for things like 'auto foo = <expr>'?

Both. And also for future deduction of storage classes by template 
functions. Basically the compiler assumes eager evaluation by default.

>> * 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.
> 
> So this is ok:
>   lazy int a = 3+4;
> And this is ok:
>   lazy int b = 3+4;
>   lazy int a;
>   a = b+2;
> 
> But this is not?
>   lazy int a;
>   a = 3+4;

That is the plan. Although probably it's a mistake.

> Don't really have any criticisms of this at the moment, just trying to 
> figure out exactly what it's going to mean in practice.
> So far what I'm getting is that it's similar to the current 'lazy' just 
> generalized to apply to more situations, and that now lazy is part of 
> the type rather than being a storage class.
> 
> Will there be any additional interop with delegates?  What about 
> assigning a delegate to a lazy variable?

That's a good idea. Frankly I am not thrilled by lazy because there is 
too much overlap with delegates to be worth any effort (and your idea 
takes that overlap to the extreme). After thinking more about it, I 
think lazy should go and automatic conversion from expressions to 
aliases should replace it as a more general and efficient alternative.

Figuring out the vagaries of each storage class and all combinations 
thereof is just a lot of effort from the creator of the language, the 
compiler implementor, and the programmer who later learns the language. 
It's even more demotivating to see that a storage class is just white 
sugar for a feature that could, and probably will, be implemented in a 
more principled way. I honestly think lazy should go. It's a waste of time.


Andrei