On 4/16/19 5:41 AM, Larry Evans via Boost wrote:
On 4/16/19 4:28 AM, Jonathan Müller via Boost wrote:
On 16.04.19 03:51, Robert Ramey via Boost wrote:
I'm way out of my depth in the variant discussion. Seems to me it revolves around all the trade offs regarding design choices. Could we perhaps decide not to decide. Suppose we create a type which looks like:
template< bool BasicGuaranteeSupported, bool StrongGuaranteeSupported, bool EmptyStateProhibited, bool AssignmentSupported, bool MoveSupported, class T ... > struct mother_of_variants{ // some trivial mp11 code };
I did something similar back when I did type_safe::variant: You have a `VariantPolicy` that controls whether the variant can be empty and a has a `change_value()` function that switches the type in whatever way it seems fit.
With that I have a `rarely_empty_variant` that is like `std::variant`, a `never_empty_variant` that assumes move is no-throw (and calls terminate() if they throw) and an `optional_variant` that fully embraces an empty state.
At the time I thought it was a good trade-off, but haven't re-evaluated it since then.
I like this; however, years ago there was some argument about how providing such a policy for smart pointers would be confusing to users. However, I didn't really agree with that argument and the alternative is, AFAICT, not much better: std::variant, or boost::variant2 or libx::variant3 or ...
Right. We could have it both ways. That is the mother of all variants could be used to generate a custom type given the requirements. For those who don't want/need to delve into all the details, we provide a list of specialization for commonly used variants which would probably address 99.9% of users needs. Robert Ramey