On 15.04.2016 22:03, Steven Schveighoffer wrote:
On 4/15/16 3:48 PM, Timon Gehr wrote:
On 15.04.2016 17:22, Steven Schveighoffer wrote:
On 4/14/16 11:10 PM, Andrei Alexandrescu wrote:
Consider:
https://github.com/D-Programming-Language/phobos/blob/master/std/range/primitives.d#L152
It works around a limitation of inout that isn't necessary (even though
I thought it was being helpful when I suggested it). That is, functions
without inout parameters cannot declare local inout variables. But this
isn't really necessary, and should be fixed. I will discuss this in my
talk in a few weeks.
...
That's potentially dangerous. What about cases like the following?
void main(){
inout(int)[] x=[1,2,3];
immutable(int) a;
int b;
inout(int)[] foo(inout int){
return x;
}
immutable(int)[] y=foo(a);
int[] z=foo(b);
}
We don't need to guess:
void foo (inout int)
{
inout(int)[] x=[1,2,3];
immutable(int) a;
int b;
inout(int)[] foo(inout int){
return x;
}
immutable(int)[] y=foo(a); // line 9
int[] z=foo(b); // line 10
}
testinout.d(9): Error: modify inout to immutable is not allowed inside
inout function
testinout.d(10): Error: modify inout to mutable is not allowed inside
inout function
I'm very aware of that: https://issues.dlang.org/show_bug.cgi?id=10758
main is not an inout function in the example above. I.e. if we just
change the compiler minimally such as to allow making inout local
variables, the above example will violate immutability guarantees. You
can also imagine cases where the inout local variable is defined only
after the local inout function has been declared and called with a
non-inout argument. At which point does the constraint become active?
etc. We cannot _simply_ allow declaring inout locals.
Note, the =0 part isn't necessary right now, since it's not called. It's
just used to test if the function can compile.
In short, my opinion on inout is that it has some unnecessary
limitations, which can be removed, and inout will work as mostly
expected. These requirements to work around the limitations will go
away.
...
Other important limitations of inout are e.g.:
- inout variables cannot be fields.
I have a way to make this work.
Without syntax changes?
Can the struct/class instances with inout fields be returned from the
enclosing inout function?
This is actually the most major sticking
point in inout.
The only correct thing is to keep is that globals/static variables
cannot be typed inout.
- There can be only one inout in scope.
This is not so much a problem I think.
...
I think it is. It's just not the prevalent limitation one runs in at the
moment. It will be more of a problem once functions can return structs
with inout fields. IMHO compositionality should be ensured for a
language feature from the start.
