On Tue, Dec 13, 2016 at 4:26 AM, Gonzalo BG
David Sankel wrote:
or if we had an suite of different variant types with different tradeoffs
Recently Boost.Hana was accepted into Boost, with its own tuple type, such that we now have boost::tuple, boost::fusion::tuple, std::tuple, and boost::hana::tuple...
I don't think this is a good situation! Hana had other merits that compensated for the drawback of introducing another tuple type. Many organizations avoid Boost for unfortunate situations just like this. So while I agree that having 4 types to do the same thing can be bad, I
would really like to hear why do you think that: - Boost.Signals2 signal type chose the right trade-offs,
In sum, I think the Boost.Signals2 model is easier to understand and use for the common case. They work a lot like function pointers, which are familiar, and the storage model is straightforward to explain. - the trade-offs chosen by Synapse's signal type are not worth the "cost"
of having two different signal types in Boost.
I didn't find a strong motivation for having another signals library with this design in the documentation nor could I come up with it on my own. I could be convinced that we really need this with some compelling motivation though notwithstanding the interface issue I raised. -- David