DIP 36: Rvalue References

Dicebot m.strashun at gmail.com
Wed Apr 10 02:31:21 PDT 2013


On Wednesday, 10 April 2013 at 09:26:38 UTC, Zach the Mystic 
wrote:
> On Wednesday, 10 April 2013 at 07:46:41 UTC, Dicebot wrote:
>> On Wednesday, 10 April 2013 at 01:40:49 UTC, Zach the Mystic 
>> wrote:
>>> I think for convenience the function must only be considered 
>>> unsafe if it does the above. Even returning the 'ref' is 
>>> @safe so long as the *caller* keeps track of what it passes 
>>> in, according to DIP25.
>>
>> Safety of "ref" is not problem that this DIP tries to solve. 
>> It should be solved with DIP25. Now ref is not safe (despite 
>> the fact it pretends to) and it still won't be after DIP36 
>> approval, not until issue is addressed in DIP25.
>>
>> No need to mix it.
>
> My proposed DIP35 uses 'scope' to enhance DIP25. I don't 
> believe DIP25 is really complete. 'scope' would help it a lot, 
> but that would give more meanings to 'scope' which are 
> potentially in conflict with it just meaning rvalue temp.

And how it is relevant to DIP36? It solves specific issue. It 
provides some hints how other DIP may use new opportunities. It 
is up to DIP25 and DIP35 to be built on top if this gets accepted 
first. Or other way around.

DIPs are built in context for current language implementation, 
not some potential other DIPs.


More information about the Digitalmars-d mailing list