On 9/06/2017 22:39, degski wrote:
It's also not uncommon for applications to have memory leaks that inevitably end in out of memory errors if left long enough.
As a former C99-guy, I would consider fixing ones' leaky applications with exceptions to be SB (Suspect Behaviour) by the developer.
There's no "fixing" involved. The simple fact is that copy-assignment will most likely throw std::bad_alloc if memory allocation is required but the available space is exhausted. And this can happen much sooner than 2GB application memory due to heap fragmentation. (In fact on average it seems to occur closer to 1.2GB, although that depends a bit on your typical object size and allocation pattern.) Most developers don't do anything to defend against this because there typically isn't any way to do so -- out of memory is usually application-fatal. As it should be. The point being that since std::bad_alloc is usually the only expected way for operator= to fail (assuming you weren't already in UB territory with a bad pointer or something), I can't think why anyone would have any expectation of exception guarantees for it in general. The exception (pun somewhat intended) to that is if some type explicitly provides additional reasons for assignment to fail -- eg. perhaps a one-time-assignable type or one that can be write-locked at runtime or something like that; but such a type should also clearly advertise what guarantees it provides in that case. The question is then whether something like variant should try to provide those same guarantees or whether (like struct) it doesn't.