On Thursday, 6 February 2014 at 15:47:44 UTC, Adam D. Ruppe wrote:
...
Had only quick look at it but here are some things to remember
that I have realised when drafting my own scope proposal:
1) passing scope arguments:
/* what to put here as qualifier? */ int[] foo(scope int[] input)
{
return input; // this should work
int[5] internal; // implictly scope
return internal[]; // but this shouldn't
}
I think it makes sense to prohibit `scope` as explicitly named
return attribute but make it inferrable via `inout`.
2) Transitivity & aggregation:
struct A
{
scope int[] slice1;
int[] slice2;
int value;
}
void foo(int[] input) { }
void boo(ref int input) { }
void main()
{
int[5] stack;
A a; // is it different from "scope A a;"?
a.slice = stack[]; // guess should be ok
a.slice2 = new int[]; // should this?
foo(a.slice1); // obviously fail
foo(a.slice2); // but does this?
boo(a.value); // I'd expect this to fail
}
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.
