Please don’t waste your time.

This user is a known troll. Nothing they propose makes sense. Ever!

Nothing will ever come out of this.

From: Std-Proposals <std-proposals-bounces@lists.isocpp.org> On Behalf Of Robin Savonen Söderholm via Std-Proposals
Sent: Wednesday, October 2, 2024 12:03 PM
To: std-proposals@lists.isocpp.org
Cc: Robin Savonen Söderholm <robinsavonensoderholm@gmail.com>
Subject: Re: [std-proposals] Not quite a template virtual function

It does not matter... Take the following example:

class virtual_foo {
  // What we see here depends on header inclusion order inside a compilation unit...
  template <typename T>

    requires(requires(T const& t) { ns::foo(t); }

  void do_foo(T const& t) { ns::foo(t); }
  public:

  virtual void foo(auto&& f) { do_foo(f); }

};

// Robin

PS: I want to point out that you may already be able to achieve what you are looking for by doing something along these lines:

template <typename T>
class base_foo_template {
public:
  virtual void foo(T t) { ns::foo(std::forward<T>(t); }

};

class my_virtual_foo : public base_foo_template<int const&>, public base_foo_template<float&&> {};

and you could even have a helper class that takes a variadic template argument to write:

class my_virtual_Foo : publix base_foo_multi_template<int const&, float&&> {};

. But it is hard to know if this is a good idea without knowing the problem you are actually trying to solve..

On Wed, Oct 2, 2024 at 11:44 AM Frederick Virchanza Gotham via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

I reply to Robin and Lénárd:


Robin wrote:
>
> That example is potentially ODR breaking as you could have
> different compilation units that see different "SomeGlobalFunction":s

Lénárd wrote;
>
> Even seeing the same functions in different order would be potentially ODR-breaking.


This can be alleviated by restricting it even further. Previously I wrote:

 "A class shall not have a non-static virtual method with the
parameter list "auto&&... args" unless the inline body of the method
contains an invocation of a non-template-and-non-variadic function
with the arguments "static_cast<decltype(args)>(args)..." -- in which
case the virtual method will be given an instantiation for each of the
overload signatures of the aforementioned
non-template-and-non-variadic function."

But we can change "non-template-and-non-variadic function" to
"non-template-and-non-variadic member function". Since you can only
have one definition of a class, there won't be any case of one
translation unit seeing member functions that another translation unit
doesn't see -- nor any case of seeing them in a different order.
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals