On Sunday, 21 May 2017 at 19:43:32 UTC, Adam D. Ruppe wrote:
> On Sunday, 21 May 2017 at 19:11:46 UTC, Stanislav Blinov wrote:
>> Looks cool, but it'd still want a GC closure, won't it?
>
> No, it just generates the same struct you'd write manually. That should work fine with @nogc now.

auto create() @nogc {
    auto y = 11;
    return lambda!(y, q{ (int x) => x+y } )();
}

Error: function create is @nogc yet it allocates closures with the GC


This:

    anon lambda() {
        anon a;
        // copy the values in
        a.tupleof = Args[0 .. $-1];
        return a;
    }

is a function that is generated by the template. It accesses the frame of create(). Am I missing something?

How recent of "now" do you mean? I've tested that with v2.075.0-master-5222639.

On Sunday, 21 May 2017 at 20:09:14 UTC, Stanislav Blinov wrote:
> is a function that is generated by the template. It accesses the frame of create(). Am I missing something?

It does access the frame, but only long enough to copy the values into the struct.... there's no reason for that to allocate....

And, indeed it doesn't if you pass the object directly to another function; only when you return it does the compiler complain (which I didn't try before posting, just passing it down the function chain like in the OP). That's annoying. The mixin will have to be moved up a level.

Blah. Well, let's go ahead and formally propose the C++ syntax, our library solutions are all fat.

On Sunday, 21 May 2017 at 20:25:14 UTC, Adam D. Ruppe wrote:

> Blah. Well, let's go ahead and formally propose the C++ syntax, our library solutions are all fat.

:)

On Sunday, 21 May 2017 at 20:25:14 UTC, Adam D. Ruppe wrote:
> Blah. Well, let's go ahead and formally propose the C++ syntax, our library solutions are all fat.

Are you going to create a DIP for this? I would be happy to contribute, but I don't feel confident enough to create a DIP on my own (I just started learning the language) :)

On Monday, 22 May 2017 at 14:06:54 UTC, Vittorio Romeo wrote:
> On Sunday, 21 May 2017 at 20:25:14 UTC, Adam D. Ruppe wrote:
>> Blah. Well, let's go ahead and formally propose the C++ syntax, our library solutions are all fat.
>
> Are you going to create a DIP for this? I would be happy to contribute, but I don't feel confident enough to create a DIP on my own (I just started learning the language) :)

The three of us could do it together through the magics of github.

On Monday, 22 May 2017 at 15:17:24 UTC, Stanislav Blinov wrote:
> On Monday, 22 May 2017 at 14:06:54 UTC, Vittorio Romeo wrote:
>> On Sunday, 21 May 2017 at 20:25:14 UTC, Adam D. Ruppe wrote:
>>> Blah. Well, let's go ahead and formally propose the C++ syntax, our library solutions are all fat.
>>
>> Are you going to create a DIP for this? I would be happy to contribute, but I don't feel confident enough to create a DIP on my own (I just started learning the language) :)
>
> The three of us could do it together through the magics of github.

I've created a very WIP draft here:
https://github.com/SuperV1234/DIPs/blob/master/DIPs/DIP1009.md

If you're interested in contributing, please let me know and I'll add you as a collaborator.

On Wednesday, 24 May 2017 at 20:15:37 UTC, Vittorio Romeo wrote:

> I've created a very WIP draft here:
> https://github.com/SuperV1234/DIPs/blob/master/DIPs/DIP1009.md
>
> If you're interested in contributing, please let me know and I'll add you as a collaborator.

Yep, I've made a small PR to make myself visible :)

On Wednesday, 24 May 2017 at 20:15:37 UTC, Vittorio Romeo wrote:
> On Monday, 22 May 2017 at 15:17:24 UTC, Stanislav Blinov wrote:
>> On Monday, 22 May 2017 at 14:06:54 UTC, Vittorio Romeo wrote:
>>> On Sunday, 21 May 2017 at 20:25:14 UTC, Adam D. Ruppe wrote:
>>>> Blah. Well, let's go ahead and formally propose the C++ syntax, our library solutions are all fat.
>>>
>>> Are you going to create a DIP for this? I would be happy to contribute, but I don't feel confident enough to create a DIP on my own (I just started learning the language) :)
>>
>> The three of us could do it together through the magics of github.
>
> I've created a very WIP draft here:
> https://github.com/SuperV1234/DIPs/blob/master/DIPs/DIP1009.md
>
> If you're interested in contributing, please let me know and I'll add you as a collaborator.

As a matter of procedure, you don't want to assign a DIP number to it yourself. I'm pretty sure that is for the DIP manager.

On Thursday, 25 May 2017 at 00:34:45 UTC, MysticZach wrote:

>> I've created a very WIP draft here:
>> https://github.com/SuperV1234/DIPs/blob/master/DIPs/DIP1009.md
>>
>> If you're interested in contributing, please let me know and I'll add you as a collaborator.
>
> As a matter of procedure, you don't want to assign a DIP number to it yourself. I'm pretty sure that is for the DIP manager.

We're well aware. The file name is not indicative of anything.

On Thursday, 25 May 2017 at 01:13:08 UTC, Stanislav Blinov wrote:
> On Thursday, 25 May 2017 at 00:34:45 UTC, MysticZach wrote:

>> As a matter of procedure, you don't want to assign a DIP number to it yourself. I'm pretty sure that is for the DIP manager.
>
> We're well aware. The file name is not indicative of anything.

The README outlines the procedure for DIP submission, including the format of the filename. The concern is that if you include number in the filename, it opens the door to people referring to it by that number. We want to avoid that.

[1] https://github.com/dlang/DIPs/blob/master/README.md