On 7/17/07, Tobias Schwinger <tschwinger@isonews2.com> 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