[Dlang-internal] DIP1000 discussion and testing: borrowing a range

[Dicebot via Dlang-internal]

On 10/21/2016 08:11 AM, Walter Bright wrote:
> On 10/20/2016 9:44 AM, Dicebot wrote:
>> This compiles too:
>>
>> ```
>> int* x;
>>
>> @safe unittest
>> {
>>     @safe static struct S
>>     {
>>         int data;
>>
>>         int* borrow () return scope @trusted {
>>             return &this.data;
>>         }
>>     }
>>
>>     S instance;
>>     x = instance.borrow();
>> }
>> ```
>>
>> Now, _this_ must be wrong, right?
> 
> 
> It compiles because you added '@trusted' to the bad boy function,
> disabling the check preventing taking the address of a 'ref'. The
> compiler has no reason to believe that the return value of
> instance.borrow() has any relationship to 'instance' - it @trusted the
> programmer to not do that!

Wait what? This is in direct contradiction with what DIP1000 states and
what I have been trying to write example of all this time. By existing
specification annotating method with `return scope` means that lifetime
of return value is same as that method `this`.

Are you saying that existing system forgets that `instance` is `this`
the very moment `borrow` methods finishes? If yes, I am afraid it is a
rather useless feature, much worse than one may think reading DIP1000.

> The practical result is that a container that is passed by ref can only
> control its uses by returning by ref, not by *.

1) Why? You still haven't answered how scope pointer is different from
ref in @safe code.
2) Does that imply that lifetime algebra as described in DIP1000 only
applies to function internal arguments and variables? As it is not
possible to neither have `ref` variables, nor take address of `ref`
return value, lifetime of return value will always be limited to single
expression.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/dlang-internal/attachments/20161021/e183750a/attachment-0001.sig>