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

[Martin Nowak via Dlang-internal]

On Saturday, 22 October 2016 at 07:38:18 UTC, Walter Bright wrote:
> If this is a class this then return scope is appropriate, 
> because this is a pointer. But when this is a ref, scope then 
> applies to the struct's fields.

Mmh, and if wanted to return a reference to the struct itself, 
we'd need to resort to return ref? Would it be possible to 
conflate return scope and return ref, at least for that use case?

>> 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.
>
> By making borrow @trusted in order to defeat the checking, you 
> defeated the connection between 'instance' the argument and the 
> return value from the function.
>
> Do not convert 'ref' to '*'. It won't work.

As said further down in this thread, it seems that returning 
casted refs (or structs containing pointers) that alias internal 
memory, but are bound/scoped to the lifetime of the comtainer, is 
a major use-case. Why can't we use this explicit scope annotation 
on a trusted method to make this work?

>>> 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.
>
> I've been trying to answer. There are two things at work for 
> variable 'v':
>
> 1. v's address
> 2. v's value
>
> 'ref' deals with the first, 'scope' with the second. It is 
> very, very, very important to think about whether you are 
> dealing with v's address or v's value, otherwise you will get 
> hopelessly lost.

Could you elaborate a bit on that?

> Next, recall that 'this' for a struct is an address. 'this' for 
> a class is a value.

The other way round, right?

> That's what scope variables are for - storing addresses in.
>
> I implore you to look at the test cases with the PR. They are 
> all trivial and easy to follow.

I hope you agree that we must check the design against our actual 
high level goals. While the breaking down the rules is a good 
approach for a formal view, being able to puzzle together the 
pieces to useful idioms is essential.