opDispatch to template members

[Era Scarecrow]

On Thursday, 6 December 2012 at 23:01:19 UTC, deadalnix wrote:
> On Thursday, 6 December 2012 at 21:49:21 UTC, Phil Lavoie wrote:
>> I mean automatically dispatch to template members, not doing 
>> it in a case by case fashion (using template if clauses for 
>> example).
>>
>> Thanks
>
> This is a known issue of the current design of opDispatch.

  It seems like there should be a way to separate template 
function calls to opDispatch and keep opDispatch's own template 
half separate. Hmmm... Some type of separator.

  It would likely have to allow a beginning tuple, as well as call 
opDispatch that would recognize it as such.

  In theory...

  auto opDispatch(T..., string method, V...)(V args)

  Assuming it would be allowed, T represents the template portion 
of a call. Since the ... makes it illegal to be first (in normal 
cases) it may allow a special rule in order to understand it's a 
passable tuple for templates only, and allowed for only the first 
and last arguments. Or would T[] be better?

  Then calling such an opDispatch may be...
  {
     static assert (!T.length) {
       return mixin("._inner." ~ method)(args);
     } else {
       return mixin("._inner." ~ method)!(T)(args);
     }
  }

  The rewrite of such a function call would be..

   auto zeOtherString = outer.fun4( zeString );
   outer.fun5!"popo"(); //No compilo amigo

   would become (I think?)

   //depending on how they do it...
   auto zeOtherString = outer.opDispatch("fun4")(zeString);
   auto zeOtherString = outer.opDispatch([], "fun4")(zeString);
   auto zeOtherString = outer.opDispatch(void[0], 
"fun4")(zeString);
   outer.opDispatch(["popo"], "fun5")();

  Having the passable tuple after the method may be confusing, but 
might equally work...

   auto opDispatch(string method, T t, V...)(V args)   (or is it 
'T[] t'?)

  Allowing a blank (for t) wouldn't probably be allowed, so two 
opDispatches might have to be made, but that might be minor. 
Depends on what makes sense and how walter/andrei decide to 
handle if (if at all).

  If it still requires a separating type, you could always use 
void...

   auto opDispatch(T[], void, string method, V...)(V args)
   outer.opDispatch(["popo"], void, "fun5")();

  or??

   auto opDispatch(string method, T[], void, V...)(V args)

   //void and non-void attempted? Or always insert void silently?
   outer.opDispatch("fun5", ["popo"])();
   outer.opDispatch("fun5", ["popo"], void)();