Peter Dimov wrote:
I wasn't planning on dropping support for automatic tracking of signals, I don't see that dropping it would make things any less confusing for the user.
Automatic tracking is nice, but is it workable, if the goal is for the 'new' signals to become part of the C++ standard library one day? It requires cooperation from the function objects, and this is hard to achieve in practice.
It's questionable if the whole idea of tracking through shared_ptr is viable for a standardization effort. I of course have no experience with this, but seeing what has been accepted into TR1, I'm a bit sceptical about a TR2 signals and similarly "rich" functionality. It would probably be better to not depend on the tracking anywhere, so that it can be dropped altogether, if it turns out impossible to come to an agreement. This would mean we get rid of the specialized handling of signals as a slot with automatic tracking (it comes cheaply with the pimpl idiom, but that's an implementation detail). If the user does not manage the connection and signal lifetime externally, they will have to use track(). That's not a big problem in my opinion. There is a bit of an ambivalence here, since we're still trying to maintain compatibility to the current Boost.Signals. I would also like to make the slot templated by the call signature instead of the storage type (that's what Boost.Signals does) as you implied in one of your examples. Otherwise the easiest way of determining the slot type is through typename signal_type::slot_type which is perhaps too inconvenient in that the exact signal type must be known. Regards Timmo Stange