On 15 September 2022 22:57:46 BST, Frederick Virchanza Gotham via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
>On Thu, Sep 15, 2022 at 9:33 PM Zhihao Yuan <zy@miator.net> 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
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals