DIP 36: Rvalue References

[kenji hara]

2013/4/10 Manu <turkeyman at gmail.com>
>
> Why are you suggesting changing scope to imply ref? This seems wrong.
> scope and ref are separate, should remain that way.
>

I say that 'scope' itself should not imply 'ref'. It is *possible* but
would break existing code meaning, so it should not be applied.


> Arguments would be scope ref, or in ref, thus allowing rvalues. Without
> ref, I would imagine that the meaning is such that, even though the
> argument is a copy, it, or members thereof are not allowed to escape.
>
> struct X { int *p; }
> int* global;
>
> void func(scope X x) // note: is not ref
> {
>   global = x.p; // <- error! scope prevents any part of x escaping, even
> though it's a copy.
> }
>
> This way, scope has meaning with or without ref.
>

That is an enhancement. Similar things is now in my mind, but it is not yet
output.


> And, 'scope' is alredy used for delegate parameter.
>>
>> int opApply(scope int delegate(ref int) dg);
>>
>> Such a semantic modification will silently change the meaning of existing
>> code. It's not good to me.
>>
>
> What does scope mean in this case? Is this a conflict in some way?
>

Compiler guarantees that given delegate to the scope parameter never make a
closure.
It would avoid heap allocation.

Kenji Hara
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130410/6a3bae9e/attachment-0001.html>