We need to have a way to say "convert this nested function into a struct"

[Jonathan M Davis via Digitalmars-d]

On Saturday, 6 June 2015 at 06:16:17 UTC, Andrei Alexandrescu 
wrote:
> Nested functions that allocate their environment dynamically 
> can be quite useful. However, oftentimes the need is to convert 
> the code plus the data needed into an anonymous struct that 
> copies the state inside, similar to C++ lambdas that capture by 
> value.
>
> I wonder how to integrate that within the language nicely.

Some of us were discussing this at dconf. Essentially, we need a 
way to create a functor similar to how C++ lambdas do. The most 
straightforward way would involve string mixins, and you'd do 
something like

auto f = makeFunctor!"function code here"(arguments);
auto result = range.algorithm!f();

but that's not terribly pretty. Atila seemed to have figured out 
how we could do it with std.functional.partial, but I was too 
tired at the time to quite understand what his proposal was. So, 
we may have something better there. Ideally, we'd be able to just 
give a lambda, but that would put us right back in the problem of 
a delegate being allocated unnecessarily (though IIRC, Atila's 
suggestion somehow worked with lambdas and partial without 
allocating; I wish that I could remember what he proposed). But 
while it may or not be as pretty as we'd like, I think that it's 
at last _possible_ for us to have a shorthand for creating a 
functor by just providing the function's body and arguments that 
hold the values for its members. I'm certainly not against 
finding a language way to make it prettier though, since I'm not 
sure how clean we can really do it without language help.

That being said, we really should find a way to make it so that 
lambda's don't turn into delegates unless they really need to. In 
many, many cases, they should be plenty efficient without having 
to force the issue with functors, but they aren't, because we 
allocate for them unnecessarily. I don't know how easy it'll be 
though for the compiler devs to figure out how to optimize that, 
since sometimes you _do_ need to allocate a closure.

But having a shorthand way to create functors would definitely 
allow us to force the issue where necessary. And from what Liran 
was saying at dconf, that alone would make it possible for them 
to use a lot of Phobos that they can't right now. I suspect that 
unnecessary closures are actually the main reason that we have GC 
allocation problems with Phobos, since most algorithms just don't 
explicitly involve allocation unless they're doing array-specific 
stuff.

- Jonathan M Davis