dan marsden wrote:

Eric Niebler wrote:

...

Tobias Schwinger wrote:

...

All it takes is yet another adapter encapsulating a type's ctor(s) in a function object to just use fusion::(invoke|fused)_function_object. E.g:

<snip>

...

Client code (at function scope):

invoke_function_object( ctor<my_class>(), argseq );

Yes, that's exactly it. Now, put it in Fusion so I don't have to write a function object with N overloads. :-)

So what is the interface that would be preferred. We can: 1) Provide class ctor<T> as part of the Fusion public interface, and let users call invoke and create fused<ctor<T> > objects.

I think that this 'ctor'-thingy should be public: It seems not too difficult to find a general use case without argument unpacking, e.g. make boost::bind applicable to constructors. However, Fusion isn't necessarily the best place for it (the stuff in boost/utility or the "Bind utilities", 'mem_fn' and 'ref', are probably better neighbors). Is there such a thing somewhere in Boost already, perhaps?

2) We can provide invoke_ctor<T> and fused_ctor<T>, implement them in terms of a private detail::ctor<T>. This might be a bit more convenient for users, and would give us more scope for optimizing this use case under the hood 3) Provide both

I don't believe there is much to optimize until someone proofs it (as the wrapper should be easy to eliminate compared to the actual unpacking - especially with nested views). Also, I'm not sure that making the library harder to learn and maintain is worth the convenience it buys. There are already too many variants (though with C++0x features things will become much better). Regards, Tobias