equivariant functions

[Steven Schveighoffer]

"Andrei Alexandrescu" wrote
> Steven Schveighoffer wrote:
>> "Andrei Alexandrescu" wrote
>>> Steven Schveighoffer wrote:
>>>> I'll reiterate my proposal:
>>>>
>>>> inout(X) f(inout(Y) y, inout(Z) z)
>>>>
>>>> where inout means 'the greatest common constancy of all variables that 
>>>> are declared inout'.  Again, not in love with inout, but inout kind of 
>>>> reads 'you get out what you put in', and it is a 'free' keyword.
>>> Ugh. This doesn't quite work because it mimics the "true" solution (= 
>>> bind an alias to the qualifier) by always calling that alias "inout" or 
>>> whatever keyword name. This problem becomes apparent when you try to 
>>> nest declarations:
>>>
>>> inout(X) fun(inout(Y) function(inout(Z)) gun);
>>>
>>> Now you tell me which inout goes where.
>>
>> That would be invalid.  You need at least one inout argument that can be 
>> implicitly casted to const.  As far as I know that can't be done with a 
>> function pointer.
>>
>> If you want to pass in a function pointer to a function which uses the 
>> inout constructs, then the inouts become literal inout.  i.e.:
>>
>> inout(Y) foo(inout(Z) x) {...}
>>
>> inout(X) fun(inout(Z) argtofoo, inout(Y) function(inout(Z)) gun) {...}
>>
>> invariant(Z) z = cast(invariant) new Z;
>>
>> auto x = fun(z, &foo);// x is of type invariant(X)
>>
>> Maybe you had a different behavior in mind?
>
> Well this:
>
> inout(X) fun(inout(Z) argtofoo, inout(Y) function(inout(Z)) gun) {...}
>
> could mean two things:
>
> 1. "Bind all inout occurrences to a qualifier and resolve the signature", 
> or
>
> 2. "Whenever inout occurs in a function parameter, don't bind it."
>
> It's not that clear-cut which is the one to be chosen, and that will have 
> to be a convention because the syntax is ambiguous.

OK, how about this:

inout(Y) function(inout(Z)) f = &foo;
auto x = fun(z, f);

What is f?  Is this not the same as passing &foo directly?

-Steve