New slides about Go

[Max Samukha]

On 10/15/2010 08:34 PM, Walter Bright wrote:
> Max Samukha wrote:

> I don't see why. They're useful enough.

I might have exaggerated. But, for example, this use case:

struct S
{
    int x, y, z;
}

ref S foo();
void bar(ref S s);

void baz()
{
     auto s = &foo();
     s.x = 1;
     s.y = 2;
     s.z = 3;
     bar(*s);
}

will not be easy. One will have to use tricks like that unsafe Ref 
struct or to move the code accessing the referenced object to another 
function. Pretty awkward.

>
>
>> 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.

Of course, you do!

> 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.

Yeah, I don't like these hidden allocations either.

>
> 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.

Indeed. Why create a stack-allocated local if it is going to be copied 
to the heap anyway?

>
>
>> 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.

I have no idea how often closures are used. I use them rarely but some 
people do crazy things with them.