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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2007-07-21 11:03:30

Stjepan Rajko wrote:
> 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

I think I'll just change 'unfused_typed' to these semantics (with two 
overloads - for const-correctness ;-) ). Hopefully those changes will 
also keep MSVC 7.1 from ICEing for the non-const operator() (see 
workaround in the code)...

<snip>

> 
> 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.

There is a consistent, intermediate state in the CVS (about a week ago),
that uses the nested 'result' directly (with 'result_of' protocol) and
checks for emptiness.

I actually considered keeping this version, documenting another concept
(refinement of Polymorphic Function Object requiring nested 'result'
that can be empty), but concluded that this approach feels wrong,
because it can't work with 'result_of', relies on result type
computation (which can be removed with the next language version) and it
complicates the conceptual perspective of things.

Reading your code (link in the follow-up post) it seems you're checking
for a similar (though not identical, because of 'result_type') concept.

> 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.  

Yep, I remember. Such a "function template emulator" is actually quite
tempting to have - I'll eventually get back to it.

Regards,
Tobias