So what does (inout int = 0) do?

[Steven Schveighoffer via Digitalmars-d]

On 4/15/16 5:17 PM, Timon Gehr wrote:
> On 15.04.2016 22:47, Steven Schveighoffer wrote:
>>
>> There's no difference between a function that declares its variables
>> inout within its parameters or one that declares them locally.
>> ...
>
> Yes, there is. Semantic analysis sees the parameter types before it sees
> the body.

I don't know what the current implementation sees the function as doing. 
The way I look at it, the function context is like an extra parameter to 
the inner function. If it contains inout data, then that needs to be 
taken into account if the inner function has additional inout parameters.

For example:

inout(int) *x;

inout(int) *foo(inout int) {return x;}

foo is really taking 2 parameters: y and the context pointer that 
contains x. It almost looks like this:

inout(int) *foo(inout int, ref inout(int) *x) { return x;}

call this with: foo(1, x)

And it won't compile.

However, call it with: foo(inout(int)(1), x);

and it should be fine, returning an inout(int)*.

>
>> They should be treated the same once the function starts compiling.
>> ...
>
> I think I have stated clearly why this is impossible. :P

Impossible or difficult to do with the current implementation?

>> At the point where we need to tag multiple pools of inout parameters,
>> the complexity of the language doesn't justify the benefits.
>> ...
>
> I think this is a funny place to draw the line, but I guess this is a
> matter of taste.

I may have said this incorrectly. The language itself wouldn't really be 
that much more complex. It's the cost of understanding what each of the 
different inout pools mean. The benefit would be quite small, whereas 
there are obvious places inout makes sense -- the 'this' parameter and 
the return value.

Then there is the syntax that would be required, I'm not sure what that 
looks like.

>> 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.
>
> Well, that is precisely the way that languages with real type systems
> address issues like this one. D has many others like it.

Aye, solutions like Rebindable, which is pretty much a failure IMO, show 
how lack of expressiveness in the core language can't be easily substituted.

> Note that for type systems, complexity and expressiveness do not
> necessarily correlate.

Humans are creatures of habit and familiarity. To allow each library to 
define what words mean what for modifiers would be really difficult to 
deal with.

-Steve