So what does (inout int = 0) do?

[Steven Schveighoffer via Digitalmars-d]

On 4/15/16 4:27 PM, Timon Gehr wrote:
> 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.

There's no difference between a function that declares its variables 
inout within its parameters or one that declares them locally.

They should be treated the same once the function starts compiling.

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

Yes, as long as inout is wrapping inout. We run into this currently with 
inout functions that create local types. e.g. emplace.

Obviously inout cannot be unwrapped if it is typed on a field of a 
struct or class. So the unwrapping has to result in 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.

At the point where we need to tag multiple pools of inout parameters, 
the complexity of the language doesn't justify the benefits.

We could make it possible, for instance, to templatize the mutability 
modifier instead of using a specific keyword. Then you could have 
foo(int)[]. Then I think you could do all this (and scrap inout), but I 
wouldn't want to work in that language.

-Steve