New slides about Go

[dsimcha]

== Quote from Denis Koroskin (2korden at gmail.com)'s article
> IIRC there was some keyword (is that static?) that forces a closure NOT to
> allocate on heap.

You're thinking of scope, and it works but it's a huge hack.  When
&someNestedFunction is evaluated in the context of a function call and the
parameter is scope, there is no heap allocation.  I've been meaning to dump a
function into std.typecons, called noHeap or something, that just takes a scope
delegate and returns it, as a way to bypass heap allocations for other cases of
taking the address of a nested function.

In general, I think this is a decent strategy:  The implicit default behavior
should be safe, easy to understand and easy to use even if it hurts performance.
Optimizations should be carried out by the compiler when it can prove they won't
affect code semantics or by the programmer when he/she can prove they're
necessary.  I wouldn't mind having &someLocal heap allocate like closures do (and
be allowed in SafeD), as long as there's an easy way to explicitly prevent this.
For example, we could use the scope trick like with closures, and have a
scopedAddress function in std.typecons that lets you unsafely take the address of
a stack variable.

> I think I'll add an optional parameter that lists all the heap-allocated
> closures to ddmd (similar to how -vtls works).

Vote++.  This would be useful after you've identified some code as the bottleneck,
to figure out why it's so much slower than it should be.