On 7/4/19 6:34 PM, Gavin Lambert via Boost wrote:
On 5/07/2019 00:08, Emil Dotchevski wrote:
Not at all. The types mentioned in Robert's message are very different, so merging them into one component makes as much sense to me as the speculation I made.
+1
Just because two types are similar syntactically, doesn't mean that they have similar semantics. For example, just because one needs variant's functionality to implement outcome, doesn't mean that semantically outcome should be e.g. an instance of some variant template.
The whole point of correct design is to remove flexibility that does not pertain to what the interface is designed to do, leaving the user with only the options that the interface designer has determined to be necessary and sufficient.
I agree, but that just suggests that the "mother of all variants" should actually be a "variant_storage" type; you can then have "variant" and "optional" etc expose only parts of its interface in their own interface, either through standard composition or through private inheritance.
+1 This makes the most sense to me. You might also parameterize the type of the index. For example, for optional, it would be a boolean type. For std::variant, it might be unsigned long. Then, like Gavin since, the interface would just be an adaptor over this "variant_storage" type. -Larry