Boost logo

Boost :

From: Larry Evans (cppljevans_at_[hidden])
Date: 2019-07-05 01:28:08


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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk