This has no effect:
_bars.each!(a => { a._plots.fillColor = Color(255, 180, 0); });

I tried putting ..each!((ref a) =>.. with no difference

This works:
foreach(b; _bars) {
	b._plots.fillColor = Color(255, 180, 0);
}

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:

import std.stdio;
import std.algorithm;

void main() {
    auto arr = [ 1, 2 ];
    arr.each!(a => { writeln(a); });  // returns lambda for each a
}

The lambda that 'each' takes above is "given a, produce this lambda". . To do the intended work, you need to remove the curly braces (and the semicolon):

    arr.each!(a => writeln(a));

Or, you could insert empty () to call the returned lambda but that would completely be extra work in this case:

    arr.each!(a => { writeln(a); }());

Ali

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:
>
> import std.stdio;
> import std.algorithm;
>
> void main() {
>     auto arr = [ 1, 2 ];
>     arr.each!(a => { writeln(a); });  // returns lambda for each a
> }
>
> The lambda that 'each' takes above is "given a, produce this lambda". . To do the intended work, you need to remove the curly braces (and the semicolon):
>
>     arr.each!(a => writeln(a));
>
> Or, you could insert empty () to call the returned lambda but that would completely be extra work in this case:
>
>     arr.each!(a => { writeln(a); }());

Or, remove the arrow:

    arr.each!((a) { writeln(a); });

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? If this is the user's intended behavior, then they can rewrite it like this to be explicit and disable the warning:

_bars.each!(a => (){ a._plots.fillColor = Color(255, 180, 0); });
//               ^^ add empty parenthesis before the curly brace

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

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.

On Monday, 2 May 2016 at 10:15:04 UTC, Marc Schütz wrote:
> On Monday, 2 May 2016 at 08:46:31 UTC, Ali Çehreli wrote:
>> [...]
>
> 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.

It's good idea. I myself stumbled into this before.

On 5/2/16 6:00 PM, sigod wrote:
> On Monday, 2 May 2016 at 10:15:04 UTC, Marc Schütz wrote:
>> On Monday, 2 May 2016 at 08:46:31 UTC, Ali Çehreli wrote:
>>> [...]
>>
>> 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.
>
> It's good idea. I myself stumbled into this before.

Agree.

-Steve

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:
>
> import std.stdio;
> import std.algorithm;
>
> void main() {
>     auto arr = [ 1, 2 ];
>     arr.each!(a => { writeln(a); });  // returns lambda for each a
> }
>
> The lambda that 'each' takes above is "given a, produce this lambda". . To do the intended work, you need to remove the curly braces (and the semicolon):
>
>     arr.each!(a => writeln(a));
>
> Or, you could insert empty () to call the returned lambda but that would completely be extra work in this case:
>
>     arr.each!(a => { writeln(a); }());
>
> Ali

This seems to work the best:

arr.each!(a => { writeln(a); }());

On Wednesday, 4 May 2016 at 04:56:54 UTC, Joel wrote:
> On Sunday, 1 May 2016 at 05:42:00 UTC, Ali Çehreli wrote:
>> [...]
>
> This seems to work the best:
>
> arr.each!(a => { writeln(a); }());

And the ugliest. And probably slowest.