Revised RFC on range design for D2

[Yigal Chripun]

Andrei Alexandrescu wrote:
> I agree. But then use of functions for invocation dwarfs use of
> functions as first-class values, so I think requiring & for the latter
> is a sensible engineering decision.

the above POV seems skewed to me. D is not C! instead of relying on old
habits we need to form new, better ones.
you basically claim here that "functions as first class values" current
usage is low therefore the syntax should be as it is, while another POV
would be to say: D is relatively a new language that aims to support
more functional programming therefore D should support functions as
first class values more than C and adjust its syntax accordingly.

> 
> Besides, it's more efficient to use them as alias parameters, so why not
> encourage that too. And aliases do not need a "&" :o).

alias parameters have cons too and the choice what to use should be
decided according to the problem at hand.

> 
> If you want to discuss language design mistakes, why don't you discuss a
> real mistake - the infamous "lazy"? Having a storage class change the
> way a type is used - now that's the perfect example of the tail wagging
> the dog. Ambiguity, confusion, non-scalability, and sheer nonsense - you
> can have it all with lazy. Lazy should be either fixed or honorably
> discharged pronto.
> 

could you please explain more about what's so bad about lazy in your
opinion?

> Andrei
>