Delegate Literals + Immutability, pure and closures

[David Nadlinger]

On 9/29/11 10:32 PM, dsimcha wrote:
> I've recently discovered this pattern to allow use of type propagation and
> immutability in these situations with no extra boilerplate:

Yes, this pattern is very useful indeed, I also often use a similar 
solution for generating code for string mixins on the fly. Do we already 
have a name for it, by the way? I like to call it »IEDL for »Immediately 
Executed/Evaluated Delegate Literal«, but that's probably just me.

> 1.  It allocates a closure.  Therefore, it can't be used in
> performance-critical code.  We really need to optimize away closure allocation
> in trivial cases where the function pointer obviously can't escape, to make
> delegate literals more useful in performance-critical code.

Definitely +1 for this, function/delegate literals are so useful in D 
that I think making them as efficient as possible should be high on our 
list. »Demoting« delegate literals that don't need to access the scope 
to function literals (as described by TDPL, don't have the issue number 
handy right now) would be a first step, and avoiding to unnecessarily 
copy frames to the heap as second, but this could turn out to be quite 
tricky.

> 2.  Delegate literals can't be inlined in even the most trivial cases.  This
> is less severe than (1), and probably would almost never have a non-negligible
> impact in practice, though.

I'd also very much like to see improvements on this front – contrary to 
what you said (if I got all that negations right), it does have a 
prohibitively large performance impact in some of my applications. 
However, I'm not quite sure how hard it would be to implement a 
solution, since inlining happens nowhere near constant folding, afaik.

> 3.  A function that uses a delegate literal can't be pure because purity is
> not inferred for delegate literals:
> […]
> 4.  Auto return type inference is limited to cases where all return statements
> return the exact type.  Is there any reason I'm missing why, if multiple
> return statements with different types are present, an auto return function
> couldn't just return a common type?

+1 for these as well, should be fairly easy to pull off.

David