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




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. 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.

-Steve

Reply via email to