On 08/17/2016 04:01 AM, Chris Wright wrote:
> On Tue, 16 Aug 2016 18:55:40 +0000, Dicebot wrote:
>> You need to add one more level of indirection for things to start going complicated.
> 
> Presumably scope is transitive, so things shouldn't get horribly complex.

It is not transitive and it is not a type qualifier.

On Wed, 17 Aug 2016 13:53:37 +0300, Dicebot wrote:

> On 08/17/2016 04:01 AM, Chris Wright wrote:
>> On Tue, 16 Aug 2016 18:55:40 +0000, Dicebot wrote:
>>> You need to add one more level of indirection for things to start going complicated.
>> 
>> Presumably scope is transitive, so things shouldn't get horribly complex.
> 
> It is not transitive and it is not a type qualifier.

Non-scope is transitive, rather -- you can't have a non-scope pointer to a scope item (at least in @safe code).

On 08/11/2016 04:38 PM, Sönke Ludwig wrote:
> That will just leave one hole in conjunction with the @trusted destructor, which is (presumably) not easy to fix without much larger changes to the type system, as well as to how container types are built. It is still vulnerable to artificial shortening of the elements' lifetime, e.g. by using opAssign() or destroy():
> 
> @safe {
>     RefCountedSlice!int s = ...;
>     scope int* el;
>     el = &s[0];
>     s = RefCountedSlice.init;
>     *el = 12; // oops
> }

I asked Walter about this in more details and right now plan is to address it in a separate DIP that provides more integration between reference counting and compiler. Within DIP1000 terms such destructor must not be marked as @safe - essentially, it will only enable @safe usage of stack allocated data in its initial form.

> A similar issue affects the library implementation of isolated memory that I did a while ago:
> 
> @safe {
>     class C { int* x; }
> 
>     // c is guaranteed to be only reachable through this variable
>     Isolated!C c = makeIsolated!C();
> 
>     // c.x is a @property that returns a specially wrapped reference to
>     // the actual C.x field - with this DIP this is similar to a 'scope'
>     // return, but acts transitively
>     Scoped!(int*) x = c.x;
> 
>     // one of the benefits of Isolated!T is that it allows @safe
>     // conversion to immutable:
>     immutable(C) ci = c.freeze();
>     // c gets cleared by freeze() to disallow any further modifications
> 
>     // but, oops, x is still there and can be used to modify the now
>     // immutable contents of ci.x
>     *x = 12;
> }
> 
> Disallowing the assignment of scope return references to local scope references (either by default, or using some form of additional inference/annotation) would solve this particular issue, but not the issue in general (the assignment/destruction could for example happen in a nested function call).

Note that using scope return in its most basic form will exactly prevent the assigning of reference to a variable because it limits lifetime to expression.

On Wednesday, 10 August 2016 at 20:35:23 UTC, Dicebot wrote:
> - Please submit pull requests to adjust the markdown document if you want to propose any improvements (mentioning @WalterBright and @andralex for confirmation).

Not completely through yet, but it looks really promising.
Already made a PR (https://github.com/dlang/DIPs/pull/34) to replace the term visibility w/ reachability, b/c visibility is already used as a replacement for access checks (DIP22) and reachability is a well established term for GC.

On Thursday, 18 August 2016 at 17:05:05 UTC, Dicebot wrote:
> On 08/11/2016 04:38 PM, Sönke Ludwig wrote:
>> That will just leave one hole in conjunction with the @trusted destructor, which is (presumably) not easy to fix without much larger changes to the type system, as well as to how container types are built. It is still vulnerable to artificial shortening of the elements' lifetime, e.g. by using opAssign() or destroy():
>> 
>> @safe {
>>     RefCountedSlice!int s = ...;
>>     scope int* el;
>>     el = &s[0];
>>     s = RefCountedSlice.init;
>>     *el = 12; // oops
>> }
>
> I asked Walter about this in more details and right now plan is to address it in a separate DIP that provides more integration between reference counting and compiler. Within DIP1000 terms such destructor must not be marked as @safe - essentially, it will only enable @safe usage of stack allocated data in its initial form.

I think RefCountedSlice can have a @trusted destructor so long as opAssign is @system. (I'll likely make a PR to the DIP soon).