DIP69 - Implement scope for escape proof references

[Walter Bright via Digitalmars-d]

On 12/5/2014 3:59 PM, deadalnix wrote:
> On Friday, 5 December 2014 at 21:32:53 UTC, Walter Bright wrote:
>>>> I don't believe this is correct. Rvalues can be assigned, just like:
>>>>
>>>>   __gshared int x;
>>>>   { int i; x = i; }
>>>>
>>>> i's scope ends at the } but it can still be assigned to x.
>>>>
>>>
>>> It work even better when i has indirections.
>>
>> I understand what you're driving at, but only a scoped rvalue would not be
>> copyable.
>>
>
> The DIP say nothing about scoped rvalue having different behavior
> than non scoped ones.

Can you propose some new wording?



>>> I originally had scope only apply to ref, but that made
>>>> having scoped classes
>>>> impossible.
>>>>
>>>
>>> Promoting scoped class on stack is an ownership problem, and out
>>> of scope (!). It make sense to allow it as an optimization.
>>>
>>> Problem is, lifetime goes to infinite after indirection, so I'm
>>> not sure what the guarantee is.
>>
>> The guarantee is there will be no references to the class instance after the
>> scoped class goes out of scope.
>>
>
> Through use of that view. I see it as follow:
>    - When unconsumed owner goes out of scope, it can (must ?) be
> free automatically.
>    - scope uses do not consume.
>    - When the compiler see a pair of alloc/free, it can promote on
> stack.
>
> That is a much more useful definition as it allow for stack
> promotion after inlining:
> class FooBuilder {
>       Foo build() { return new Foo(); }
> }
>
> class Foo {}
>
> void bar() {
>       auto f = new FooBuilder().build();
>       // Use f and do not consume...
> }
>
> This can be reduced in such a way no allocation happen at all.

Yes, but I think the proposal allows for that.


>>> I cause everything reached through the view to be scope and
>>> obliviate the need for things like &(*e) having special meaning.
>>
>> Are you suggesting transitive scope?
>
> For rvalues, yes. Not for lvalues.

I don't think that is workable.