On Mon, May 27, 2024 at 8:12 PM Lorand Szollosi wrote:
>
> By this logic, std::factory<>() were also a core language
> change, as it's impossible to implement in terms of currently
> existing language features.


That's not how it works. Let's use "std::has_virtual_destructor" as an example.

"std::has_virtual_destructor" cannot be implemented using standard
C++. It needs compiler support (aka "compiler magic"). But here's the
wording copy-pasted directly from the C++23 Standard:

    Template: template<class T> struct has_virtual_destructor;
    Conditions: T has a virtual destructor (11.4.7)
    Pre-conditions: If T is a non-union class type, T shall be a complete type.

The Standard doesn't even mention that this particular function needs
compiler support. The Standard doesn't care that it cannot be
implemented without compiler support. The Standard just dictates,
"This will work the way I say it does". Anyway here's a typical
implementation of it:

    template<typename T>
    struct has_virtual_destructor {
        inline static constexpr bool value = __has_virtual_destructor(T);
    };

The compiler support here is the operator "__has_virtual_destructor".
This is not considered to be a "core language change" because the
"__has_virtual_destructor" operator is not made available to the
programmer to use in their own code.


> Simply wrapping it into a library function doesn't change this fact.


It does change the fact. Asking for a standard library function that
needs compiler support is not a core language change.


> This brings a whole new set of pandora boxes: functions that don't
> specify return type on declaration, thus linker introspection is required,
> calling convention changes for the allocation, type system breaks (how
> does std::nrvo "know" that the return type of Func2 is std::mutex?


That was a mistake I made in my last post. I should have written:

    std::nrvo<mutex>(Func);

You're right that a function's return type is not included in its
mangled name -- but even if it was, we've already wiped it out and
replaced it with 'void'.


> What if we call Func directly?


You're forbidden to directly call a function that contains a call to
"std::return_slot". Such a program is ill-formed, and the compiler
must issue a diagnostic. You're only supposed to invoke the function
pointer returned by a constant-evaluated invocation of "std:nrvo".


> What if there are two uses of std::nrvo in Func, with different types assumed?
> What if coder doesn't use std::construct_at<>() but uses something else?).


Again, ill-formed, and the compiler must issue a diagnostic.