So what does (inout int = 0) do?

[Timon Gehr via Digitalmars-d]

On 15.04.2016 23:56, Steven Schveighoffer wrote:
> 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,

Rather, when the inout data is actually accessed.

> then that needs to be
> taken into account if the inner function has additional inout parameters.
> ...

That's sensible, of course. The current implementation is a lot more 
conservative though.

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

What I'm saying is that the check that is currently implemented is not 
adequate for the new case. This is not terribly important though. The 
point was that there needs to be a design effort beyond lifting the 
limitation, and you seemed to claim that the current implementation 
already takes care of the presented issue, which is not the case.

Your ideas are sound though.


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

They would just be named parameters to the function on the type system 
level, similar to template arguments but not causing repeated instantiation.

> The benefit would be quite small, whereas
> there are obvious places inout makes sense -- the 'this' parameter and
> the return value.
> ...

The return value might contain more than one pointer, and functions 
often have more than one parameter.

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

Anything that is analogous to template parameters, e.g. an additional 
set of arguments with a different delimiter. Many workable 
possibilities. Anyway, it is unlikely to happen.


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

I don't see how the library would do that.