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
