On 15 September 2022 22:57:46 BST, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>On Thu, Sep 15, 2022 at 9:33 PM Zhihao Yuan <zy_at_[hidden]> wrote:
>>
>> I agree that variant<monostate, Cat, Dog>
>> can be a model for
>> variant<specify_base<Animal>, Cat, Dog>,
>> but I also want variant<Cat, Dog> to
>> implement an Animal interface.
>> To summarize, I think
>>
>> nonnull
>> nullable
>> throwing
>>
>> All make sense.
>>
>> How about this:
>>
>> template<class T>
>> struct implements
>> {
>> template<class... Ts>
>> using model = std::variant<Ts...>;
>> };
>>
>> template<class T>
>> struct implements_nullable
>> {
>> template<class... Ts>
>> using model = std::variant<std::monostate, Ts...>;
>>
>> static auto default_proxy() noexcept { return nullptr; }
>> };
>>
>> template<class T>
>> struct implements_or_throw
>> {
>> template<class... Ts>
>> using model = std::variant<std::monostate, Ts...>;
>> };
>
>
>It isn't immediately apparent to me how you would use those. Something
>like the following?
>
> implements<Animal>::model<Dog,Cat,Fish> obj;
>
> obj->Eat();
>
>The whole point of my proposal is to have this simple syntax:
>obj->BaseClassMethod();
>
>I want it to all be inside "std::variant" so that the object can be
>used in templates that expect an std::variant,

I would prefer a "variant-like" concept for this, that defines the common interface between variant and your type.

> and also so that the
>"std::variant" object can be copied and it will still retain all of
>its info (which wouldn't happen if we made a new class derived from
>"std::variant").

I didn't propose deriving from variant, bet even so, all the data members are in the variant, slicing wouldn't lose information here.

Cheers,
Lénárd