equivariant functions

[KennyTM~]

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);
> 
> I think this could work and doesn't look half bad. Of course, you'll be 
> tasked with addressing protests about yet another D1/D2 incompatibility. 
> :o)
> 
> 
> Andrei

I'm afraid the meaning of inout here is very unclear without explanation.