Oh interesting. So to answer your question then we first:

- I would prefer using "static virtual" instead of inventing a new keyword again "static_virtual";

- The usage of good olds and forgotten template templates could be useful here.

template <typename T>

struct base

{

    static virtual void static_virtual_function();

};

template <typename T>

struct derived_type : base<T>

{

    static virtual void static_virtual_function();

};

template <typename T>

struct independant_type

{

    static virtual void static_virtual_function();

};

template <template <typename> class C : base, typename T> // new syntax

void foo(C<T> &bar)
{
    bar.static_virtual_function();
}

derived_type<int> d;

foo(d); // would call derived_type::static_virtual_function

independant_type<int> i;

foo(i); // would fail to compile right now and won't create tons of nested error messages


On 3/17/21 7:44 PM, Ryan P. Nicholl wrote:
It isn't:

https://wandbox.org/permlink/HmXv4vCV1g38ImBz

vtable is still generated.

--
Ryan P. Nicholl
Tel: (678)-358-7765

Tox: 52B3A61CDAF88BCC854F568933F071E3530600CDBA3D5354AADC9AD179575D68021AE959719D


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, March 17, 2021 7:28 PM, Phil Bouchard <boost@fornux.com> wrote:

Ville already answered that this feature is already available:

https://wandbox.org/permlink/ChfCIDJPiYomLrfO


On 3/17/21 7:18 PM, Ryan P. Nicholl wrote:
No, what I am saying is what happens if you have a function like:

void foo(derived_type &bar)
{
bar.static_virtual_function();
}

how is that supposed to be compiled?


Sent from ProtonMail mobile



-------- Original Message --------
On Mar 17, 2021, 19:10, Phil Bouchard < boost@fornux.com> 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.


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@fornux.com> 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@lists.isocpp.org> 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
--

Phil Bouchard
Founder
C.: (819) 328-4743
Fornux Logo
--

Phil Bouchard
Founder
C.: (819) 328-4743
Fornux Logo
--

Phil Bouchard
Founder
C.: (819) 328-4743
Fornux Logo

--

Phil Bouchard
Founder
C.: (819) 328-4743

Fornux Logo