My 5 cent here:

In PHP there is something called "late static binding". I am a PHP
programmer, but used it only once in production.

Technical explanation is very difficult and I am not sure I understand it
correctly,
but it allows to execute overridden static method in child class:

https://www.php.net/manual/en/language.oop5.late-static-bindings.php

I believe it will be interesting to take a look.

I must say, PHP is a language derived from C (not C++), but all classes are
Java like - all non-static methods are virtual,
so every PHP class has vtable (or even pointer to all methods) and is not
difficult to do functionality like that.

Nikolay


On Fri, Mar 19, 2021 at 12:05 AM Phil Bouchard via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
> On 3/18/21 2:46 PM, Phil Bouchard via Std-Proposals wrote:
>
> Double-checking here...
>
> As long as there's an equivalent to pure virtual at compile-time (forcing
> derived classes to override required member functions) other than
> explicitly adding concepts for each member functions.
>
> I guess I would add inheritance to concepts then. I think you all
> understand what I mean here and why...
>
>
>
> On 3/17/21 11:59 PM, Ryan P. Nicholl wrote:
>
> 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 < ldalessa_at_[hidden]> 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
> [image: Fornux Logo] <http://www.fornux.com/>
>
> --
>
> *Phil Bouchard*
> Founder
> C.: (819) 328-4743
> [image: Fornux Logo] <http://www.fornux.com/>
>
> --
>
> *Phil Bouchard*
> Founder
> C.: (819) 328-4743
> [image: Fornux Logo] <http://www.fornux.com/>
>
> --
>
> *Phil Bouchard*
> Founder
> C.: (819) 328-4743
> [image: Fornux Logo] <http://www.fornux.com/>
>
>
> --
>
> *Phil Bouchard*
> Founder
> C.: (819) 328-4743
>
> [image: Fornux Logo] <http://www.fornux.com/>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
> --
>
> *Phil Bouchard*
> Founder
> C.: (819) 328-4743
>
> [image: Fornux Logo] <http://www.fornux.com>
>
> --
>
> *Phil Bouchard*
> Founder
> C.: (819) 328-4743
>
> [image: Fornux Logo] <http://www.fornux.com>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>