I think the C++17
variant type offers an interesting look at the language vs. library issue.
variant type has had a long and semi-torturous history in its development. The big issue has been how to deal with throwing constructors during assignment/emplacement into a live
The obvious desire would be to provide the strong exception guarantee: if the new object throws during copy/move/emplace into the
variant, then the
variant is left unchanged. But implementing that has problems. The desired
sizeof for a
variant is that of an equivalent
union + a
char to discriminate within them.
Which means that if you assign/emplace into a variant, 2 things have to happen: destroy the old value, then construct the new value in its place. It's #2 that fails; the old value is gone. You can't get it back.
You could try to play games, like moving the old value into a temporary, then moving it back if the construction of the new fails. But move operations are allowed to throw, and there are even standard library types with throwing moves. You can try to double-buffer the data (store 2x the data, so you always have a temporary around), or even allocate memory like
boost::variant, but those were considered unacceptable by the committee.
For a language-based
variant, this would obviously not be an issue. The standard would simply declare by fiat that it offers the strong exception guarantee and that it is sized appropriately, doesn't allocate memory, etc. Compilers would have to use compiler magic to make it work.
However... what if we could simply expose that "compiler magic" as a first-class language feature? For example, this proposal suggests a way to effectively make move constructors that don't throw. By doing that, we can now use the temporary method to implement
This gives you most-if-not-all of the advantages of a language
variant, but it also gives you tools you can use to make your other code more efficient.
If you try to shove anything and everything into the language, what you'll find is that you'll make users overly dependent on the language, rather than using the language to give users the tools to build what they need. This is especially important for a low(er)-level language like C++.