[Dlang-internal] DIP1000 discussion and testing

[Martin Nowak via Dlang-internal]

On Monday, 24 October 2016 at 19:49:10 UTC, Walter Bright wrote:
> On 10/23/2016 11:49 PM, Dicebot wrote:
>> On 10/24/2016 05:29 AM, Walter Bright wrote:
>>> On 10/22/2016 3:50 PM, Dicebot wrote:
>>>> Beauty of borrowing is that it allows to to inc/dec skipping 
>>>> with no
>>>> special RC support from compiler and works the very same for 
>>>> stack
>>>> allocated data. What you are going at is simply replacing GC 
>>>> with
>>>> (compiler enhanced) RC and that is not good at all.
>>>
>>> I don't see why supporting something beyond RC and GC is 
>>> necessary.
>>
>> Both GC and RC are forms of automatic memory management with 
>> unavoidable
>> associated overhead. Both have their uses but are unacceptable 
>> in most
>> of the system code. Which means that would would either need to
>> duplicate all Phobos/druntime functions to work with both RC 
>> and plain
>> pointers or it will become even less suitable for low level 
>> code than it
>> is now.
>
> I'm afraid that is a bit vague. Can you give a more concrete 
> example?

Also important are Unique ownership (handing out scoped 
references to internal (untyped) memory) and ranges that cannot 
outlive their containers.

>> - allow taking address of a `ref` and define lifetime of such 
>> expression
>> to be same of `ref` lifetime
>
> Again, why? Why can't the function return by 'ref'?

While returning by ref is good enough to prevent escaping, and we 
do use it in RefCounted for structs, it doesn't allow you to bind 
that returned value anywhere.
So you could only chain method calls 
s.get.call.getNested.doSome.foo.bar;.

While that might be fine as a first step, it doesn't seem to need 
scope/return scope, and is fairly limiting in the mid-term.

>> - `return scope` of a struct methods binds returns value 
>> lifetime to one
>> of the struct instance itself, not composition of its fields
>
> 'ref' return already does that.

Would it be possible to conflate the two different annotatons 
with similar but slightly different semantic? Couldn't return 
scope on the method mean, that a reference to the whole struct 
can be returned.