On 6/27/19 1:53 PM, Niall Douglas via Boost wrote:
Robert, you may find studying Outcome's strong_swap() of interest.
I certainly would if I were going to implement the mother of all variants.
Ref page: https://ned14.github.io/outcome/reference/functions/strong_swap/
Implementation: https://github.com/ned14/outcome/blob/develop/include/outcome/detail/value_s...
tldr; implementing the strong guarantee is much harder than it looks, and actually offers surprisingly little benefit in practice. It's also a pain to implement without making constexpr puke, at least in C++ 14. All in all, the weak guarantee is likely plenty good for almost everybody almost all of the time.
Here you've exactly hit on the motivation for mother of all variants. It should be clear by now that as library developers we cannot correctly anticipate the needs and desires of our potential users and at the same time document the rational and restrictions of the particular variant in question. Ramey's law. When something is really hard to do - do something else. That something else would be to a) familiarize oneself with all the discussions of the different kinds of variants b) synthesize these discussions to a template meta programming class policy and related english document. This class would implement the mapping "set of properties" => variant class. If a given set of properties could not produce such a class it would be a compile time error. c) make a couple of examples and tests d) make aliases for outcome, expected, boost variant, std variant boost variant2, std optional, boost optional. e) each of the above aliases should be a one statement template instantiation of the above tmp policy class. f) If e) is not possible, you're not done, go bact to b above. that is what I'm suggesting is possible and that some ambitious person undertake to accomplish.
Niall
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost