scope escaping

[Adam D. Ruppe]

On Thursday, 6 February 2014 at 22:04:05 UTC, Dicebot wrote:
> I think it makes sense to prohibit `scope` as explicitly named 
> return attribute but make it inferrable via `inout`.

I think it is very important to put on the return value 
explicitly so it can be used to control access to a sealed 
resource.

Perhaps returning a scope var would make it easy enough to infer 
though.


> 2) Transitivity & aggregation:
>     A a; // is it different from "scope A a;"?

Probably not because A is a value type. Even if you explicitly 
marked it scope, it wouldn't really matter. Any pointer to it 
should be scope since it is on the stack though.

>     a.slice2 = new int[]; // should this?

Yeah, it should. Here's how I'm seeing the struct: let's just 
decompose it to a list of local variables. So "A a;" is 
considered by the same rules as
    scope int[] a_slice1;
    int[] a_slice2;
    int a_value;

as if they were written right there as local variables. A struct 
is conceptually just a group of variables, after all, let's treat 
it just like that.

>     foo(a.slice2); // but does this?

Thus this is ok too, since it would work if we used the local var 
a_slice2.

> void boo(ref int input) { }
>     boo(a.value); // I'd expect this to fail

I actually think that should work. Let's try to imagine what 
problems could come up in boo:

int* global;
void boo(ref int input) {
    global = &input;
}

That is a problem... but it is almost ALWAYS a problem. Unless it 
happened to be passed a heap int by ref, this would always fail.

I think taking the address of a ref parameter should be allowed, 
but should always yield a scope pointer. You can't be sure it 
isn't on the stack, so you don't want to escape that address.... 
perhaps ref implies scope? If you want a pointer to escape, ask 
for a pointer. Moreover, I think address of a stack var should 
also be scope, so

void storeMe(int* i) {}
void test() {
    int i;
    storeMe(&i); // fails: address of stack var yielded scope var 
which cannot be passed to non-scope parameter
}

Otherwise though, writing to a ref is ok, even if it is on the 
stack. If boo just wants to read and update the value, that's ok.


> Main problem with strict scope definition is that most seem to 
> inuitively get what it is expected to do but defining exact set 
> of rules is rather tricky.

Yeah, structs definitely complicate things, but I think 
pretending they are just a bunch of local variables gives us a 
consistent and useful definition.