On Thursday, 20 May 2021 at 11:40:24 UTC, Ola Fosheim Grostad wrote:

Well they do... sort of.

You can always take the address of a struct member function and now you have your nogc delegate.

Of course the difficulty is the receiving function has no way to knowing if that void* it received is a struct or an automatically captured variable set or what.

And the capture list takes a little work but there's tricks like making it all in a struct.

I wrote about this not too long ago:
http://dpldocs.info/this-week-in-d/Blog.Posted_2021_03_01.html#tip-of-the-week

However the delegate itself is less useful than a functor or interface though unless you must pass it to existing code. And then unless it is a scope receiver you're asking for a leak anyway again because of that void* being unknown to the caller (which is why this is possible at all, but also it leaves you a bit stuck).

It would be kinda cool if the compiler would magically pack small types into that void* sometimes. Since it is opaque to the caller it could actually pack in a captured int or two right there and be a by-value delegate.

On Thursday, 20 May 2021 at 12:10:31 UTC, Adam D. Ruppe wrote:

Yes, what C++ lacks is a way to type a lambda (function object) before it is defined. A solution could be to have a way to say: this delegate should be able to hold 2 ints and 1 double, then it would have buffer space for that and there wold be no need to allocate. Libraries could provide aliases that are shorter, obviously.

On Thursday, 20 May 2021 at 12:42:51 UTC, Ola Fosheim Grostad wrote:

You can do this with functors.

On Thursday, 20 May 2021 at 12:53:08 UTC, deadalnix wrote:

Yes, but the point is to declare a delegate with internal closure buffer without knowing what it receives?

On Thursday, 20 May 2021 at 13:12:30 UTC, Ola Fosheim Grostad wrote:

It is more tricky, but some implementation of std::function do that. If what's captured is small enough, they store it in place, if it is larger, they allocate.

It is not mandated by the standard and the size after which they'll allocate is implementation defined when they do, not under the user's control.

On Thursday, 20 May 2021 at 13:48:01 UTC, deadalnix wrote:

Yes, but sizeof std::function is always the same?

True, but D could be smarter and do something similar, but allow the size to vary so that you can save memory. And if you only assign once, then the cost of having a larger buffer in the delegate is smaller than if you do many assignments.

D can be smarter than C++ because it can generate IR for all D files, I think?

On Thursday, 20 May 2021 at 12:31:00 UTC, Steven Schveighoffer wrote:

Yeah... Honestly, that getting-around-immutable thing seems like the nail in the coffin for the current behavior. Hopefully making it work "correctly" won't be too painful...

The delegate-related thing I really want improved is being able to capture local variables in places like:

int i = 3;
someRange.map!(x => x.thing == i).each!writeln;

...without needing the GC, since we "know" that i doesn't escape. Dunno if that's a pipe dream, though.

On Friday, 21 May 2021 at 00:31:52 UTC, TheGag96 wrote:

int i = 3;
someRange.map!(x => x.thing == i).each!writeln;

This has to be an aim. It's simply stupid that using map in the way it's intended to be used results in a GC allocation (there are workarounds, but this is missing the point entirely). I know it won't be easy, but quite frankly if it's not possible that's a knock on us and our infrastructure - if we can't do big and important things properly we need to change that too.