• Dukc (57/57) Jun 16 2018 I think I have just found a pattern to ease the pain of @nogc
• jmh530 (2/4) Jun 17 2018 I like it.
• Seb (5/6) Jun 17 2018 It would even be better if map can recognize tuples and thus
• Dukc (2/9) Jun 17 2018 Yes, I agree. And each too, of course.
• Dukc (7/8) Jun 17 2018 Thought again and not so sure anymore: I just realized that if we
• Seb (3/9) Jun 18 2018 Yep, I'm aware of this and that's the argument why it has

Dukc <ajieskola gmail.com> writes:

I think I have just found a pattern to ease the pain of  nogc 
programming somewhat. Consider this:

import std.algorithm;
import std.range;

 nogc void main()
{   import core.stdc.stdio;
     int power = 2;
     foreach
     (   raised;
         iota(10)
         .dropOne
         .map!(num => num^^power)
     ) printf("%d\n", raised);
}

It won't compile, because the lambda argument on map uses the 
local variable power. Compiler thinks it must allocate that 
variable in heap, using gc, lest the lambda function could 
overlive power.

So that is probably one big reason for complains about Phobos 
when you can't use the garbage collector. This hurdle won't make 
it useless, though. You can avoid the problem this way:

import std.algorithm;
import std.range;

 nogc void main()
{   import core.stdc.stdio;
     int power = 2;
     foreach
     (   raised;
         iota(10)
         .dropOne
         .zip(power.repeat)
         .map!(arg => arg[0]^^arg[1])
     ) printf("%d\n", raised);
}

It works, but arg[0] and arg[1] are fairly much book examples on 
how to NOT name your variables.

But with a little bit of help, the library can still do better:

import std.algorithm;
import std.range;

 nogc void main()
{   import core.stdc.stdio;
     int power = 2;
     foreach
     (   raised;
         iota(10)
         .dropOne
         .zip(power.repeat)
         .map!(tupArg!((num, pow) => num^^pow))
     ) printf("%d\n", raised);
}

alias tupArg(alias func) = x => func(x.expand);


Yes, it makes the syntax heavier, and in a simple case like this 
it's arguable whether it's worth it.

But for me at least, when the complexity of the map alias 
parameter starts rising, having the ability to name your 
variables definitely pays back.

What are your thoughts? Do you agree with this coding pattern?

jmh530 <john.michael.hall gmail.com> writes:

On Saturday, 16 June 2018 at 11:58:47 UTC, Dukc wrote:
 snip]

 What are your thoughts? Do you agree with this coding pattern?

I like it.

Seb <seb wilzba.ch> writes:

On Saturday, 16 June 2018 at 11:58:47 UTC, Dukc wrote:
 What are your thoughts? Do you agree with this coding pattern?

It would even be better if map can recognize tuples and thus 
allows to simply use a lambda functions with two parameters, but 
in the past with a few exceptions there hasn't been much 
support/consensus on specializing Phobos functions for tuples.

Dukc <ajieskola gmail.com> writes:

On Sunday, 17 June 2018 at 13:50:31 UTC, Seb wrote:
 On Saturday, 16 June 2018 at 11:58:47 UTC, Dukc wrote:
 What are your thoughts? Do you agree with this coding pattern?

 It would even be better if map can recognize tuples and thus 
 allows to simply use a lambda functions with two parameters, 
 but in the past with a few exceptions there hasn't been much 
 support/consensus on specializing Phobos functions for tuples.

Yes, I agree. And each too, of course.

Dukc <ajieskola gmail.com> writes:

On Sunday, 17 June 2018 at 20:17:36 UTC, Dukc wrote:
 Yes, I agree. And each too, of course.

Thought again and not so sure anymore: I just realized that if we 
are to do that, it should apply the same changes to tee, find, 
filter etc. Probably too complicated to be worth it.

For  nogc, there's also always hope that we will be able to mark 
delegates scope, and with -dip1000, use local variables directly 
again.

Seb <seb wilzba.ch> writes:

On Monday, 18 June 2018 at 06:54:46 UTC, Dukc wrote:
 On Sunday, 17 June 2018 at 20:17:36 UTC, Dukc wrote:
 Yes, I agree. And each too, of course.

 Thought again and not so sure anymore: I just realized that if 
 we are to do that, it should apply the same changes to tee, 
 find, filter etc. Probably too complicated to be worth it.

Yep, I'm aware of this and that's the argument why it has 
previously been rejected.