possible "solution" for ufcs

[Lutger Blijdestijn]

Steven Schveighoffer wrote:

> Someone wrote a very compelling argument for ufcs (uniform function call
> syntax) for ranges, and that is, given a slew of range functions, and a
> slew of ranges, it is nice to use a fluent programming syntax to specify
> wrappers for ranges without having to extend each range type.  For
> example:
> 
> take(10,stride(2,cycle([3,2,5,3])));
> 
> vs.
> 
> [3,2,5,3].cycle().stride(2).take(10);
> 
> And I thought damn it would be nice if ranges could implement ufcs, but
> other types that you didn't want to allow infinite extendability could
> avoid it.  That gave me an idea :)
> 
> 
> import std.stdio;
> 
> struct ufcs
> {
>      auto opDispatch(string name, T...)(T args) // appropriate if compiles
> constraint here
>      {
>          mixin("return ." ~ name ~ "(this, args);");
>      }
> }
> 
> int foo(ufcs x, int y)
> {
>      writefln("it works! %d", y);
>      return y+1;
> }
> 
> void main()
> {
>      ufcs u;
>      auto x = u.foo(1);
>      assert(x == 2);
> }
> 
> And it does indeed work (2.053)...
> 
> So we can have ufcs without any changes to the compiler, and we also make
> it a *choice* for people who don't want to allow infinite extendability,
> and don't want to deal with possible compiler ambiguities.
> 
> The opDispatch could even be a mixin itself (I think).
> 
> What do you think?
> 
> -Steve

Nice and clever! However, I don't think it's good as an alternative for ufcs 
in the language, unless that is going to be dropped because of too many 
ambiguities.

ufcs should imho be a decision on the caller side or the side of the 
function extending a datatype (like extension methods in C#), not the 
implementor of a datatype. It should ideally be available out of the box, to 
be used with any type.