[jjdisn]

Honest question: what's wrong with std::variant? I'm quite fond of using it.

Sure it has trade offs like being empty by exception, but that's necessary if you don't want it to allocate.

Also, pattern matching would be nice instead of std::get with visitor, but that's more of a language issue than an std::variant issue

[rwbt]

Everytime I have to use std::get<> and std::visit<> I feel like the committee has failed all of us.

[TwentyPosts]

> that's necessary if you don't want it to allocate.

Wait, what does one have to do with the other?

[OskarS]

I'm not totally 100% on this, but:

valueless_by_exception happens when the move assignment operator throws (which should never happen in good C++, but is not disallowed by the language). That means, the variant used to hold value X, we were moving value Y into it, but the move assignment operator failed. What is now the state of the variant? It's not X, since we started running the move constructor, which could have started destroying the old value before throwing. But it's not Y either, because the constructor didn't finish. So what's the value that's being held? The answer is that there is no valid value.

How could this be fixed using allocation? Well, if you assume that std::variant allocated, it could be implemented in such a way that the std::variant just held a pointer to a heap area which stored the actual contents of the value. When you move assign, you construct a new element on the heap and move into that.

If the move assignment completes successfully, you swap the old value pointer for the new one and destroy the old value. But if move assignment/construction fails, you just retain the old pointer: nothing has been destroyed, and the variant still holds a valid value. This is very similar to the "strong exception guarantee" for std::vector, which is violated if the move assignment operator for the value throws.

This is one of many reasons why the move constructor/assignment operator should always be noexcept: there's no reason why it should ever throw, and it violates a bunch of these kinds of guarantees.

I think, anyway. I would be happy to be corrected if I got this wrong.

[bidune]

Yes exactly. Maybe being able to select the implementation strategy would have been nice, but I personally prefer noexcept constructors to an allocating variant