equivariant functions

[Andrei Alexandrescu]

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