So what does (inout int = 0) do?

[Steven Schveighoffer via Digitalmars-d]

On 4/15/16 6:31 PM, Timon Gehr wrote:
> On 15.04.2016 23:56, Steven Schveighoffer wrote:
>>
>> 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.

I'm sorry, should have put on my standard disclaimer that I am not a 
compiler writer :) I actually have no idea how this is done in the 
compiler, just how a compiler should behave as I understand it in my head.

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

Right, but again: these are named by the writer of the template, not the 
language, right? In that case, any identifier becomes a modifier. Or are 
you thinking of something different?

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

Of course, but the transference of mutability from parameter to return 
value is the obvious draw of such a wildcard. In most cases, there is 
only one return value, and therefore only one pool that needs to be handled.

ref/out parameters can serve as alternate returns as well as composed types.

It's not that functions don't have multiple returns with their own 
inout, but I don't think it's very common. As we get more and more 
obscure, the cost/benefit ratio for complexity vs. power gets higher. 
And already people don't like where we are right now with it.

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

Especially given the discussion happening here, I agree.

>> 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.
>>
>
> I don't see how the library would do that.

Just throwing a strawman out there:

void foo(bingo = inout, zingo = inout)(bingo(int)* x, zingo(int)* y)

So inside foo, bingo is one flavor of inout, zingo is another. This 
could vary library to library, function to function.

It would work, and be sound design. I would just hate it is all :)

Perhaps you have a better system in mind?

-Steve