DIP 36: Rvalue References

Manu turkeyman at gmail.com
Tue Apr 9 23:07:01 PDT 2013


On 10 April 2013 15:30, kenji hara <k.hara.pg at gmail.com> wrote:

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

Right. Absolutely agree then! :)



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

I think this is a tool that will greatly enhance working with @safe in the
future. I look forward to it.


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

Do you have any ideas/solutions that still fit this proposal?
I tend to think the value of this proposal is of extreme significance to D.
It is, without doubt, the single biggest complaint I've heard by virtually
every programmer I've introduced D to, and the future implications for
@safe improvements are valuable too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130410/8e20f1cc/attachment.html>


More information about the Digitalmars-d mailing list