equivariant functions

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> "Andrei Alexandrescu" wrote
>> Steven Schveighoffer wrote:
>>> "Andrei Alexandrescu" wrote
>>>> I discussed with Walter a variant that implements equivariant functions 
>>>> without actually adding an explicit feature to the language. Consider:
>>>>
>>>> typeof(s) stripl(const(char)[] s);
>>> As another point on this, I think someone else mentioned it, but I can't 
>>> find the post.
>>>
>>> I don't like the way this looks.  The way it reads is 'stripl returns the 
>>> same type as s', but really, the typeof(s) is actually modifying the type 
>>> of the argument also.  This seems very unintuitive.
>> I agree. We need to look for a better notation.
>>
>>> I understand the need to not change the language, but I think most would 
>>> prefer a syntax where the type modifier is specified on at least the 
>>> argument.  People are going to be extremely confused when they can't 
>>> treat 's' like a normal const(char)[].
>>>
>>> If the ultimate result is that no intuitive syntax can be made without 
>>> changing the language, then I think it is more important to have this 
>>> feature than to not change the language.
>>>
>>> One other syntax that Janice proposed (and I later put into a bugzilla), 
>>> is to use the dead keyword inout.  Meaning, what you send in is what you 
>>> get out.  ref already completely replaces inout, so there is no need to 
>>> keep it under its current meaning:
>>>
>>> inout(char)[] stripl(inout(char)[] s);
>>>
>>> I'm not in love with this completely, but it has the benefit of not 
>>> requiring a new keyword.
>> Also I guess:
>>
>> class C
>> {
>>     Range!(inout(C)) foo() inout;
>> }
>>
>> And also:
>>
>> class Base {}
>> class Derived : Base {}
>> inout foo(inout Base b);
> 
> In this last example, what does the inout mean at the front?

Accept and return any subtype of Base.

Andrei