The implementation of variant in C++17 is very different than in Boost. The Boost variant has a double buffer for the entire variant, and one of these buffers is always kept on the heap even if your variant is on the stack! This acts as a safety net incase the changing of the variant's value were to throw, you can get the old value back.

This implementation did not fly for C++'s goal of being high performance, and thus the new standardized variant is done quite differently.

I did not have a good experience with boost::variant ... Compile times increased drastically, compiler error messages became enormous and garbled with templates, syntax was onerous in places (e.g. "make_recursive_variant"), and identification of types is based on arbitrary index value that is risky to rely on (which() method). I ended up refactoring the whole thing, removing boost::variant and just using the traditional visitor pattern. The only advantage boost::variant really has over traditional C++ visitor pattern is that boost static_visitor functions can have a non-void return type ... Being able to directly return a value in the visitor functions is admittedly very convenient, but the other issues negate this convenience.

My understanding is it is partly an enabling step to later introduce some sort of pattern matching along the lines of the work Bjarne had been doing so new syntax will likely come.

> but it doesn't open up new capabilities the way that new syntax does

Taking very normal so-what code and moving it into the standard is pretty much the point. Having variant in std:: lets new code use variants without adding a boost dependency. I say that without knocking on boost. Fewer dependencies are always better.