Setting a list of values

[Marc Schütz via Digitalmars-d-learn]

On Monday, 2 May 2016 at 08:46:31 UTC, Ali Çehreli wrote:
> On 05/01/2016 12:54 PM, Xinok wrote:
> > On Sunday, 1 May 2016 at 05:42:00 UTC, Ali Çehreli wrote:
> >> On 04/30/2016 10:05 PM, Joel wrote:
> >> > This has no effect:
> >> > _bars.each!(a => { a._plots.fillColor = Color(255, 180, 0);
> >> });
> >>
> >> This is a common issue especially for people who know
> lambdas from
> >> other languages. :)
> >>
> >> Your lambda does not do any work. Rather, your lambda
> returns another
> >> lambda, which is promptly ignored:
> >
> > Those are some discrete semantics. I know D pretty well and
> even I
> > didn't see the problem initially. Anybody else think it's
> worth adding a
> > warning to the compiler for this specific case?
>
> A warning would be great but I don't see how it can cover all 
> cases. A special warning for std.algorithm.each might work but 
> this exact issue appeared on the main thread just a few minutes 
> ago:
>
>   
> http://forum.dlang.org/post/qsayoktyffczskrnmgxu@forum.dlang.org
>
>     alias funType = void function(int x);
>     funType fun = (x) => { assert(x); };   // cannot return 
> non-void from void function
>
> Ali

Warning (better: disallowing altogether) about `=>` directly 
followed by `{` should be enough to cover all cases. To express 
that you really want a lambda returning a lambda, it can be 
rewritten either as:

     (x) => () { assert(x); }

or as:

     (x) => ({ assert(x); })

This check can be done purely by looking at the tokens. Should we 
someday introduce tuples with `{}`, the check needs to be done 
after the node starting with `{` has been parsed to distinguish 
between delegate and tuple literals.