equivariant functions

[Jason House]

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);

I don't like how those who are unaware of this feature will misinterpret the
meaning of the function signature.

What about use as function arguments?  I had to refactor a lot of
interface-based code because some code needed exact types and the casting
to/from interfaces was a significant performance hit.


> 
> This signature states that it returns the same type as an argument. I
> propose that that pattern means stripl can accept _any_ subtype of
> const(char)[] and return that exact type. Inside the function, however,
> the type of s is the type declared, thus restricting its use.
> 
> I need to convince myself that function bodies of this type can be
> reliably typechecked, but first I wanted to run it by everyone to get a
> feel of it.
> 
> Equivariant functions are not (necessarily) templates and can be used as
> virtual functions. Only one body is generated for one equivariant
> function, unless other template mechanisms are in vigor.
> 
> Here are some examples:
> 
> a) Simple equivariance
> 
> typeof(s) stripl(const(char)[] s);
> 
> b) Parameterized equivariance
> 
> typeof(s) stripl(S)(S s) if (isSomeString!S);
> 
> c) Equivariance of field:
> 
> typeof(s.ptr) getpointer(const(char)[] s);
> 
> d) Equivariance inside a class/struct declaration:
> 
> class S
> {
>      typeof(this) clone();
>      typeof(this.field) getfield();
>      int field;
> }
> 
> What do you think? I'm almost afraid to post this.
> 
> 
> Andrei