My recommendation would be not to provide comparison operators if either `T` or `EC` does not provide them.
Agreed. Logged to https://github.com/ned14/outcome/issues/107
The trick with catch-reswap-rethrow assumes that `T` is more likely to throw while swapping/moving than `EC`, but it might be quite the opposite. Also, it is possible that while reswapping, another exception will be thrown. In general, you cannot guarantee the roll-back, so maybe it would be cleaner for everyone if you just declared that upon throw from swap, one cannot rely on the state of `result`: it should be reset or destroyed.
So, don't bother attempting to restore a valid state at all? Does everybody else agree?
Another problem is that in the noexcept() clause you are mentioning is_nothrow_swappable
and is_nothrow_swappable , but in the implementation you might be using move constructors rather than swaps. This means that for types that do not throw in swap but throw in move constructor (like std::list), a throw from move constructor will cause a call to `std::terminate`. See live example here: https://wandbox.org/permlink/8jIyb0fx7U72cZSt
Surely if std::is_nothrow_swappable tells lies, it is only right that that equals std::terminate? In other words, if the STL traits tell me that `swap(A, B)` does not throw, and then it throws because it's implemented with move constructors, that's surely not my problem?
Plus, documentation does not mention that the swap provides only a basic guarantee.
Agreed. Logged to https://github.com/ned14/outcome/issues/108. Thanks for the feedback! Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/