DIP 36: Rvalue References

[Zach the Mystic]

On Wednesday, 10 April 2013 at 09:31:22 UTC, Dicebot wrote:
>>> 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.

I would say, if you are going to use a keyword ('scope' in this 
case) to mean something, and there are other uses of the keyword 
which are also useful, you have to decide first if there is a 
conflict, and second how it should be resolved. In my opinion 
there is a conflict. The only existing definition of 'scope' 
parameters we have suggets that it means the parameter may not be 
escaped. It turns out that such a parameter is possibly necessary 
to successfully seal references in D. If a different proposal 
wants to use the word to mean something else, then it's important 
to decide either that two different features require two 
different parameter attributes (DIP36 understands this, and 
proposes several alternate possibilities to use), or that each 
feature can always automatically include the other feature 
without any problems (possible but see my other responses), or 
that only one feature is truly important enough to be included in 
the language, allowing you to disregard the other feature 
entirely.