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_at_[hidden]> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>