No API to prepend a slot

[LordVolumeForm]

In sigc++-3.0 direct access to the slots list via slots() was removed. Previously, this made it possible to add a slot at the start of the list of slots, rather than at the end as connect() does. Now, this is no longer possible. Not only is there no direct API to do it, even attempting to implement it using the various base classes of sigc::signal invariably runs into the need to access the signal_impl, which is in a detail namespace so should not be accessed.

• Is there any intended way to prepend a slot using sigc++ that I may have missed?
• Is there any way at all to prepend a slot using sigc++?
• If not, what alternative are application developers intended to move to?

Note that this isn't a particularly serious problem as I can work around it.

[kjellahl]

signal::slots() was deprecated 6 years ago with the comment This is apparently not useful,
but please let us know if you need it. AFAIK you're the first one to tell us that you miss it.

It would be possible to add slots() to sigc++-3.0, but if you just want to be able
to add slots at the beginning of the list, I'd prefer to add a method that does
just that. What should such a method be called? prepend() had been fine, if the
opposite had been append(). But prepend()/connect() is not a good pair.
What about connect_first()?

[LordVolumeForm]

I'm happy to close this without further action. I've realised the code I was trying to port can be written in a better way without connect_first. Adding such a function can wait until someone comes along who really needs it.

[LordVolumeForm]

Reopening, because as it turns out, someone really does need it.

I've realised the code I was trying to port can be written in a better way without connect_first.

Not so; attempting to rewrite that extremely fragile code didn't go well, and introduced this crash. Instead, I ended up emulating the removed feature using a vector of sigc::signals. But this is crummy and also nontrivial to implement correctly in all corner cases (I didn't), sometimes that sigc++ takes care to get right.

As the above case study shows, connect_first is effectively impossible to emulate correctly without reimplementing large parts of sigc++. So removing it makes the library substantially less powerful, in that there are problems you can no longer solve with it without reimplementing it from scratch. Given that the internal machinery is still there and only the API is missing, I think this is an argument for adding it back.

[LordVolumeForm]

Blimey that was fast! Thank you!