[Dlang-internal] DIP1000 discussion and testing

[Martin Nowak via Dlang-internal]

On Sunday, 16 October 2016 at 13:45:42 UTC, Dicebot wrote:

To summarize the current state, the Skype call with Walter 
cleared most of the misunderstandings, DIP1000 is about 2 simple 
points.

- make scope work (fix all escaping whatsoever)

It's more complex than return ref because pointers, other than 
references, can be bound to variables, hence the lifetime algebra.

Since it was already possible to create pointers in @safe code 
(ubyte[] a
= staticArray[];), and we finally can prevent escaping of 
pointers,
DIP1000 also includes allowing to take the address of sth. in 
@safe
code, similarly to how &ary[$] is now possible (see 
https://github.com/dlang/dmd/pull/6253).

- add return scope to allow returning scoped arguments (or sth. 
derived
from them)

The current state is to conservatively assume the return value 
has the
minimum lifetime of all return scope parameters (no smartness 
about
possible aliasing of return value to parameters), even for 
@trusted
functions. This should enable RC/Unique like patterns or ranges on
containers.

- Adding scope inference for parameters and variables, we already 
have return inference from DIP25.

Inference will make this actually usable, otherwise we'd end up 
with a huge amount of required extra annotations.

====================

Open questions from my side:

- what about unwanted/incorrect return scope inference

Mixed return branches would conservatively assume a scoped return 
value?
Is this a valid use-case? Should at least work with @system code.

int* func()(int* arg, bool allocate)
{
     return allocate ? new int : arg;
}

- what about return ref without scope

Does return ref on parameters makes sense without scope?
Can you take the address of an unscoped return ref result?