I think they are, and more importantly, I think C++ is moving in the direction of discouraging OOP in favor of generics + concepts. Inheritance in OOP tends to cause more problems than it solves. There are certainly use cases for it but I think most of them are better solved with variants or interfaces (which must be implemented via templates as C++ has no first class interfaces, closest we have are concepts and abstract classes.).

Now sure sometimes inheritance/polymorphism can make sense, but I'm not generally a fan of it in most cases. The biggest problem is lack of built in copy support by C++. Interfaces implemented with templates can easily support copying without the many to many implementation issues with polymorphism. You need a separate "clone" call for each interface you support via polymorphism, but copy construction can be implemented by an interface via compile time dynamic dispatch tables (type erasure). That has to be an advantage, imo, for type erasure over OOP.

Sent from ProtonMail mobile

-------- Original Message --------
On Mar 17, 2021, 8:14 PM, D'Alessandro, Luke K wrote:

>>>>> -------- Original Message --------
>>>>> On Mar 17, 2021, 19:10, Phil Bouchard < boost_at_[hidden]> wrote:
>>>>>
>>>>>> - A runtime virtual table needs an indirect lookup to the proper member function, based on its type;
>>>>>>
>>>>>> - At compile-time there is no need for these indirect lookups.
>>>>>>
>>>>>> The compiler will fail if you do not use a derived type. The idea is to create cleaner, safer header libraries and not tons of error messages because the error can be isolated more easily.
>
> Are you sure these concerns aren’t already resolved through the use of concepts?
>
> Luke
>
>>>>>> On 3/17/21 7:01 PM, Ryan P. Nicholl wrote:
>>>>>>
>>>>>>> Ok, so your proposal is that the code runs in compile time, so how is it faster? Some kind of runtime/compile time hybrid?
>>>>>>>
>>>>>>> Does the compiler fail to compile if it can't figure out the assigned type at compile time? Isn't this the same use case as auto?
>>>>>>>
>>>>>>> Why is this better than type deduction using auto &? What can be accomplished that cannot be done using type deduction?
>>>>>>> -------- Original Message --------
>>>>>>> On Mar 17, 2021, 18:50, Phil Bouchard < boost_at_[hidden]> wrote:
>>>>>>>
>>>>>>>> Like I said, it won't create a virtual table and much faster resulting code when handled at compile-time.
>>>>>>>>
>>>>>>>> On 3/17/21 6:46 PM, Ryan P. Nicholl via Std-Proposals wrote:
>>>>>>>>
>>>>>>>>> And what would this *do* that function overriding does not?
>>>>>>>>>
>>>>>>>>> -------- Original Message --------
>>>>>>>>> On Mar 17, 2021, 17:12, Phil Bouchard via Std-Proposals < std-proposals_at_[hidden]> wrote:
>>>>>>>>>
>>>>>>>>>> It won't create a run-time virtual table.
>>>>>>>>>>
>>>>>>>>>> On 3/17/21 5:03 PM, Andrey Semashev via Std-Proposals wrote:
>>>>>>>>>>
>>>>>>>>>>> On 3/17/21 10:41 PM, Phil Bouchard via Std-Proposals wrote:
>>>>>>>>>>>
>>>>>>>>>>>> New keyword proposal to allow inheritance at compile-time. Ex:
>>>>>>>>>>>>
>>>>>>>>>>>> template <typename T>
>>>>>>>>>>>>
>>>>>>>>>>>> struct container
>>>>>>>>>>>>
>>>>>>>>>>>> {
>>>>>>>>>>>>
>>>>>>>>>>>> static_virtual T * begin() {...}
>>>>>>>>>>>>
>>>>>>>>>>>> static_virtual T * end() {...}
>>>>>>>>>>>>
>>>>>>>>>>>> static_virtual T * rbegin() {...}
>>>>>>>>>>>>
>>>>>>>>>>>> static_virtual T * rend() {...}
>>>>>>>>>>>>
>>>>>>>>>>>> };
>>>>>>>>>>>>
>>>>>>>>>>>> template <typename T>
>>>>>>>>>>>>
>>>>>>>>>>>> struct list : container<T>
>>>>>>>>>>>>
>>>>>>>>>>>> {
>>>>>>>>>>>>
>>>>>>>>>>>> static_virtual T * begin() {...}
>>>>>>>>>>>>
>>>>>>>>>>>> static_virtual T * end() {...}
>>>>>>>>>>>>
>>>>>>>>>>>> static_virtual T * rbegin() {...}
>>>>>>>>>>>>
>>>>>>>>>>>> static_virtual T * rend() {...}
>>>>>>>>>>>>
>>>>>>>>>>>> };
>>>>>>>>>>>>
>>>>>>>>>>>> template <typename T>
>>>>>>>>>>>>
>>>>>>>>>>>> ostream & ostream(ostream & out, container<T> const & c)
>>>>>>>>>>>>
>>>>>>>>>>>> {
>>>>>>>>>>>>
>>>>>>>>>>>> for (auto i = c.begin(); i != c.end(); ++ i)
>>>>>>>>>>>>
>>>>>>>>>>>> out << * i << endl;
>>>>>>>>>>>>
>>>>>>>>>>>> return out;
>>>>>>>>>>>>
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> int main()
>>>>>>>>>>>>
>>>>>>>>>>>> {
>>>>>>>>>>>>
>>>>>>>>>>>> list<int> l;
>>>>>>>>>>>>
>>>>>>>>>>>> l.push_back(1);
>>>>>>>>>>>>
>>>>>>>>>>>> l.push_back(2);
>>>>>>>>>>>>
>>>>>>>>>>>> l.push_back(3);
>>>>>>>>>>>>
>>>>>>>>>>>> cout << l << endl;
>>>>>>>>>>>>
>>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> I'm not sure how it is different from the good old virtual.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> Phil Bouchard
>>>>>>>>>>
>>>>>>>>>> Founder
>>>>>>>>>> C.: (819) 328-4743
>>>>>>>>>> [Fornux Logo](http://www.fornux.com/)
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Phil Bouchard
>>>>>>>>
>>>>>>>> Founder
>>>>>>>> C.: (819) 328-4743
>>>>>>>> [Fornux Logo](http://www.fornux.com/)
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Phil Bouchard
>>>>>>
>>>>>> Founder
>>>>>> C.: (819) 328-4743
>>>>>> [Fornux Logo](http://www.fornux.com/)
>>>>
>>>> --
>>>>
>>>> Phil Bouchard
>>>>
>>>> Founder
>>>> C.: (819) 328-4743
>>>> [Fornux Logo](http://www.fornux.com/)
>>
>> --
>>
>> Phil Bouchard
>> Founder
>> C.: (819) 328-4743
>>
>> [Fornux Logo](http://www.fornux.com/)
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals