So what does (inout int = 0) do?

[Timon Gehr via Digitalmars-d]

On 15.04.2016 05:10, Andrei Alexandrescu wrote:
> Consider:
>
> https://github.com/D-Programming-Language/phobos/blob/master/std/range/primitives.d#L152
> ...


Related: Phobos should never use is(typeof(...)). Contrary to popular 
belief, is(typeof(...)) is not the same as __traits(compiles,...).

void main(){
     int x;
     static void foo(){
         static assert(is(typeof({return x;})));
         static assert(!__traits(compiles,{return x;}));
     }
}


typeof suspends context access checks. This is almost never what you 
want when checking for compilability.

>
> There is no explanation to it in the source code, and the line blames to
> https://github.com/D-Programming-Language/phobos/pull/2661 (irrelevant).
>
> Commenting it out yields a number of unittest compilation errors,
> neither informative about the root of the problem and indicative as to
> how the parameter solves it.
>
> There are two issues here:
>
> 1. Once a problem/solution pair of this degree of subtlety crops up, we
> need to convince ourselves that that's sensible. If we deem it not so,
> we look into improving the language to make the problem disappear.
> ...

Declaring variables with inout in their type is only allowed for stack 
variables in functions that have inout parameters. The (inout int) trick 
attempts to allow such types to be ranges.

It is not even a correct fix: Most of Phobos code assumes that ranges 
be struct fields. The following code causes a compilation failure in the 
guts of std.algorithm:

inout(int)[] foo(inout(int)[] x){
     static assert(isInputRange!(typeof(x)));
     return x.map!(x=>x).array;
}


What good is an "InputRange" that does not support map?


The fundamental problem is that inout is disallows certain kinds of 
composition. It's a flawed language primitive. The way to fix this is to 
have parametric polymorphism in the language.