
Frank Mori Hess wrote:
The problem is that we don't get to return an optional, because the return type is specified as "T", not "optional<T>". And, unfortunately, we can't rely on there always being a default constructor there.
Right now, the implementation is allowed to crash if you call one of these signals and there are no slots. Throwing an exception brings some sane defined behavior to something that is now completely undefined.
If we could reliably detect default-constructibility, we might be able to come up with something better.
We could add a little header with a definition of a "last_optional" combiner for people to use if they prefer.
Yes, that'd be nice. I think a non-throwing partial specialization (or a simulated one for compilers that don't support it) of last_value would be good. I've come across another problem that I find difficult to solve: Since signals are not copyable, the current implementation reference-wraps them when they're used as a slot target. The proper lifetime-dependency is established by signals being trackable subclasses, but we agreed that this won't work with thread-safe signals. Our weak_ptr-based solution doesn't work well when the tracked object is the actual target function object. Any suggestions? Regards Timmo Stange