So it's a form of specialization where a non-virtual function in the base
class will be recompiled when used in a derived class, with the compilation
context being that "this" would be the derived class instead of the base
one? So:

class EditorBase
{
    enum dummy = 1;
public:
    static virtual void Clear() {};
    static virtual void Insert( std::string x ){}
    static virtual void InitBuffer( Clear(); Insert ( "*empty*" ); printf
("%d", dummy ) }
};

class RealEditor : public EditorBase
{
  enum dummy = 2;
public:
   std::string m_buffer;
   static virtual void Clear() override { m_buffer = ""; }
   static virtual void Insert( std::string x ) override { m_buffer += x; }
};

Would create a RealEditor class where IntiBuffer actually does something,
as if Clear and Insert were virtual. Would it print "2" or "1"?

Useful, but : I'm curious about how many cases there are for this that the
compiler couldn't conceptually handle the devirtualization for
automatically. especially with "final" and link time code generation.?

On Wed, Mar 17, 2021 at 5:16 PM D'Alessandro, Luke K via Std-Proposals <
std-proposals_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
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>