equivariant functions

[Andrei Alexandrescu]

Aarti_pl wrote:
> I don't want to push once again my solution for templates from "Uniform 
> syntax" thread, but it seems that my solution would work also in this 
> case as it is another type of pattern matching.
> 
> My comments inlined.
> 
> 
> Andrei Alexandrescu pisze:
>> Many functions return one of their parameters regardless of the way it 
>> was qualified.
>>
>> char[] stripl(char[] s);
>> const(char)[] stripl(const(char)[] s);
>> invariant(char)[] stripl(invariant(char)[] s);
>>
>> Stripl is not a particularly good example because it needs to work on 
>> wchar and dchar too, but let's ignore that aspect for now.
>>
>> There's been several proposals in this group on tackling that problem.
> 
> Q(char)[] stripl(Q : Q(char)[] s);

It was my first choice. Walter would rather avoid it for implementation 
difficulty reasons.

> It is not template, so it should be putted into "runtime parenthesis". 
> In first case (function taking char[]) Q will be evaluated to nothing 
> and will be skipped.

And that's part of the difficulty: there is one more type of alias, and 
now it could even expand to nothing.

>> In unrelated proposals and discussions, people mentioned the need for 
>> functions that return the exact type of this:
>>
>> class A { A clone(); }
>> class B : A { B clone(); }
>>
>> How can we declare A.clone such that all of its derived classes have 
>> it return their own type?
> 
> In this case I would just use typeof(this)
> 
> class A { typeof(this) clone(); }
> class B : A { typeof(this) clone(); }
> 
> I don't see a reason why it should be same as in above case.

Because you don't want B's implementor to implement clone to return an 
A. That would be a mistake.

>> It took me a while to realize they are really very related. This is 
>> easy to figure out if you think that invariant(char)[] and char[] are 
>> subtypes of const(char)[]!
>>
>> 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);
> 
> This solution seems to me quite unclear. I would prefer if something 
> better would be invented.

Yah me too.


Andrei