equivariant functions

[Steven Schveighoffer]

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

>> and for 3:
>>
>> X f(return X x);
>>
>> where return means 'this function will return x'.  The return statements 
>> in this function are all required to return the value of x.  (x cannot be 
>> rebindable inside the function).
>
> I think this is a bit too particular and too restrictive to be useful. 
> Maybe we can all be happy with whatever solution we find for the general 
> case. It's not that much to type afterall.

I agree that the usefulness is not huge.  But there is no other compiler 
checkable way to guarantee that it can do the cast.  If the function in 
question doesn't know about the derived type, how can it generate a new 
instance that can be casted to the derived type?  It MUST return the exact 
argument.

The only possible other use is for typedefs, but if you are using typedefs, 
there isn't a huge incentive if you want to use them exactly like the base 
type.  And I don't want to define all functions in this style just in case 
someone has typedef'd the return type, and they want the compiler to 
auto-cast back to the typedef'd type.

I'll note that I can live without case 3, as the usefulness is low.

-Steve