scope escaping

[Marc Schütz" <schuetzm at gmx.net>]

(I see now that Adam already talked about this in his second 
post, but I'm posting it anyway, as I suggest a different 
solution.)

On Thursday, 6 February 2014 at 15:47:44 UTC, Adam D. Ruppe wrote:
> c) Calling methods on a struct which may escape the scope is 
> wrong. Ideally, `this` would always be scope... in fact, I 
> think that's the best way to go. An alternative though might be 
> to restrict calling of non-pure functions. Pure functions don't 
> allow mutation of non-scope data in the first place, so they 
> shouldn't be able to escape references.

As a consequence of this, it would no longer be possible to 
manage an owned object that has a back-pointer to its owner, e.g:

class Window {
     Menu _menu;
     this() {
         _menu = new Menu(this);    // cannot pass `this`
     }
     ~this() {
         delete _menu;
     }
}

class Menu {
     Window _parent;
     this(Window parent) {
         parent = _parent;
     }
}

This can probably be solved somehow. Allowing `scope` as a type 
constructor and doing the following might work, but I'm not sure 
about the safety implications:

class Window {
     scope Menu _menu;
     this() {
         _menu = new Menu(this);    // `new` returns a scope(Menu)
     }
     ~this() {
         delete _menu;              // either explicitly or 
implicitly
     }
}

class Menu {
     scope Window _parent;
     scope this(scope Window parent) {
         parent = _parent;
     }
}

(Note that this assumes scope isn't the default.)

The trick is to recognize that we can basically treat 
constructors and destructors as having a scope that starts when 
the constructor is entered and ends when the destructor returns. 
`this` can be seen as being declared inside this scope.

For member fields, `scope` also means "owned". Therefore, it 
needs to be destroyed when the scope is left (which in this case 
means: when the object is being destroyed). Thinking about this 
some more, this might even be a good idea for local scope 
variables too. This would basically mean undeprecating `scope` 
for classes. Anyway, this behaviour guarantees that the reference 
no longer exists after the object is destroyed.

`this` must me marked as `scope`, which causes `new` to return a 
scoped reference. This necessary to keep it from being assigned 
to non-scope variables. Consider the following situation:

class Menu {
     scope Window _parent;
     scope this(scope Window parent) {
         parent = _parent;
     }
}

Menu a;
void foo(scope Window w) {
     a = new Menu(w);               // not good, trying to assign 
to non-scope
     scope Menu b = new Menu(w);    // ok
}

On the other hand, I already see at least one problem:

class SomeClass {
     scope SomeClass other;
}

void foo(scope SomeClass a) {
     scope SomeClass b = new SomeClass;
     a.other = b;    // ouch
}

In Rust this is solved by the concept of lifetimes, i.e. while 
both `a` and `b` are scoped, they have different lifetimes. It's 
disallowed to store a reference to an object with a shorter 
lifetime into an object with a longer lifetime.