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.
