Re: [boost] [fusion] Re: more help with unfused_typed (previously off-list)

From: Stjepan Rajko (stipe_at_[hidden])
Date: 2007-07-17 14:03:09

On 7/17/07, Tobias Schwinger <tschwinger_at_[hidden]> wrote:
> Christian Holmquist wrote:
> > My question is how to disable the call operators with fewer arguments
> > than specified by Sequence, generated by unfused_typed<F, Sequence>.
> > Before the switch to boost::result_of one could specialize the result
> > struct to only handle the expected Sequence type, thus disabling
> > unwanted operators. I'm not familiar with boost::result_of to describe
> > this however.
>
> ... I removed that kind of control over the overload sets of the Fusion
> functional adapters (you can't pass emptiness through result_of), but
> I'm not really happy about it.
>
> <snip code>
> > Any ideas?
> Currently I think it might be best to re-add that mechanism for the
> 'unfused_*' adapters, either by checking nested 'result' of the target
> function for emptiness (exploiting SFINAE where applicable) or by
> introducing a special type (e.g. 'fusion::undefined_function'), that
> when returned from 'result_of' disables the overload...
>
> Thoughts anyone?
>

Sure... like Christian, initially I was expecting that unfused_typed
would give me only the overload with all of the types, but then when I
saw what it did it wasn't too hard to follow the instructions and
disable all of the other overloads.  Now that that mechanism is gone,
the fusion::undefined_function seems like a replacement that would
work.  Let's see - in that case could you even do something like this,
when result_of becomes a typeof-forwarder:

// warning: not too well thought over code
struct foo
{
   template<typename Seq>
   typename enable_if<is_right_kind_of<Seq>, type>::type operator()...

   template<typename Seq>
   typename disable_if<is_right_kind_of<Seq>,
fusion::undefined_function>::type operator()...
};

and that way the user wouldn't need to know about result_of any more, right?

Although, if there is a need for specifying that a function should not
be called a certain way, maybe it should have a more generic
treatment, like boost::undefined_function for starts?  Just in case
someone needs to tell both fusion and something else to stay away, for
the same function object.

Hmm... now that I think of it, I guess in something I was working on I
implemented a "has_result_of" trait that checks for either existence
of result_type, or the right result overload... that might also work
here, but I'm not sure how my has_result_of implementation fares, and
whether it can be fixed to use result_of directly (i tried and failed
for some reason) and also work when result_of is a typeof forwarder.
So I don't know about whether this might also be an avenue.

Well, that's my thoughts :-)  Thanks for asking.  In my code I'm using
something like a unfused_typed_inherited which inherits the unfused
function (because I need it to have both the original fused operator
and the unfused operator).  I think I showed it to you at some point,
although I got rid of that whole "unfusing the constructor as well"
business.  Anyway, in that one I only use the overload with all
specified args, since that's all I need anyway.

Cheers,

Stjepan