[Dlang-internal] DIP1000 discussion and testing

[Martin Nowak via Dlang-internal]

On 12/18/2016 06:59 AM, Walter Bright wrote:
> On 12/17/2016 8:03 PM, Martin Nowak wrote:
>> On Saturday, 17 December 2016 at 07:29:17 UTC, Walter Bright wrote:
>>> On 12/16/2016 9:08 AM, Mathias Lang wrote:
>>>> As long as we have:
>>>> - A way to take the address of `scope` pointers
>>>
>>> Taking the address of a scope pointer is invalid, I'll fix the method
>>> you used
>>> to do it.
>>
>> What is the reasoning for disallowing that?
> 
> scope is not transitive, and there's no way to declare a scope pointer
> to a scope pointer.

That's not really a reason, it's a symptom of the implementation and
design ;).
Let me suggest a reason, transitive scope checking would be more complex
to implement, is it that?

>> Is dealing with second order indirections (scope int**) somehow
>> different from
>> from other escape checks?
> 
> Yes. Only the top level is checked. By disallowing taking the address of
> a scope variable, only the top level needs to be checked.

The biggest limitation of return ref (DIP25) was that there was no way
to obtain indirections (e.g. a named pointer variable).
Hence you'd always need to write (and execute) a.b.c.d.e, with no way to
store temporary results (tmp = a.b.c; tmp.d.e).

No we get 1, but only 1, level of indirections (`tmp = &a.b.c;
tmp.d.e`). Two questions that arise from that.

- How certain are we that this is enough? In other words, why is `tmp =
&a.b; tmp2 = &tmp.c; tmp2.d.e` not necessary.

- Let's imagine for a short moment, what it would mean to make scope
transitive at a later point, if we'd ever find enough reasons to do so.
Maximizing future options is always good.

  - Allowing `&scoped` would be simple b/c it doesn't compile atm.
  - Changing `lifetime(*p) = ∞` to `lifetime(*p) = p` later, could be
harder I guess. How restricting would it be to already add it now?
  - The requirement for `ptr = &var` that `lifetime(var) >=
reachability(ptr)` would remain the same.


Hope I fully got the point, I'm not that much into the details of
DIP1000, so please correct me if that's nonsense.