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?

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.

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.

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.

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.

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.