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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to