New slides about Go

Walter Bright newshound2 at digitalmars.com
Fri Oct 15 10:34:39 PDT 2010


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.


More information about the Digitalmars-d mailing list