equivariant functions

[Andrei Alexandrescu]

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.


Andrei