Const template

[Tom S]

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.


> confuses lazy/delegates with expression templates,

For a good reason. If I remember correctly, Walter compared lazy 
evaluation to expression templates in his earlier posts.


> and fails to provide both a solid argument for 'lazy'

The arguments popped up in various discussions on the NG and #d on IRC.


> and the shade of a valid design for it.

It was a suggestion for one possible way to avoid breaking existing code 
- not a final and complete proposal. I was hoping for a discussion to 
follow.


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

Actually, inout/out can be detected by templates and std.bind does it. 
Still, inout cannot be distinguished from out.


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


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.


--
Tomasz Stachowiak