On Fri, 15 Oct 2010 21:34:39 +0400, Walter Bright
<newshou...@digitalmars.com> wrote:
Max Samukha wrote:
On 10/15/2010 12:32 PM, Walter Bright wrote:
The example relies on taking the address of a ref in a safe function.
To
close this hole, it appears that should be disallowed.
And disallowing it makes references not so useful.
I don't see why. They're useful enough.
What I like about Go's solution is that it is consistent with closures.
When a group of locals escape with a closure (that is when the address
of the local function using that group is taken) they are copied to
heap. When a local escape by ref (that is when the address of the local
is taken), it is also copied to heap.
I understand how it works. There is a downside to it, though. In D2,
closures get copied to the GC heap if there is a possibility of an
escaping reference. A lot of people complain about this being unexpected
hidden overhead.
The trouble with "copy any ref'd local to the heap" automatically
happening is the biggest advantage of passing by ref (efficiency) is
automatically lost. Even if it does not escape, it is copied to the heap
anyway, as you point out below.
What I don't like about Go's closures/addresses-to-locals and D's
delegates is that stuff is heap-allocated implicitly and by default. Go
has even gone (sorry) as far as allocating copies *every* time the
address of a local is taken.
Exactly. (Though D won't do the copy if it can prove that the delegate
does not escape.)
That reminds me of the argument about "new" being necessary for classes
because it makes the heap allocation explicit. It is difficult to say
good-bye to "new" but at the same time we are somehow happy with
implicitly allocated closures.
I think that implicitly allocated closures are a lot less common than
passing a local by reference.
IIRC there was some keyword (is that static?) that forces a closure NOT to
allocate on heap.
I think I'll add an optional parameter that lists all the heap-allocated
closures to ddmd (similar to how -vtls works).
