@llvm/issue-subscribers-clang-frontend

This is broken by 0fd9c37

It compiles with -fno-builtin-std-forward_like.

This is not a regression because your code has undefined behaviour (you modify the std namespace). To do these "polyfills" safely, you need to do something like this:

namespace my_namespace {
#ifdef __cpp_lib_forward_like
    using std::forward_like;
#else
    // your definition for forward_like
#endif
}

Though I do agree the given warning is confusing, and might be a sign that the implementation of the builtin wouldn't work with a conforming library implementation of forward_like (though [forward]p8 seems to say the return type is not auto&&)

Thanks for the reply, and yes it's definitely UB but indeed the error message threw me off (I would expect it to complain about a redefinition). But then again, why isn't __cpp_lib_forward_like defined properly?

Edit.
Alright, got it. It's not fully implemented yet (AFAICT), and overall things are broken as soon as one puts stuff inside the std namespace so I reckon after that all bets are already off anyways.

Reopening for reconsideration because https://github.com/microsoft/STL/blob/f98b286a17e7c72e3fa10297868b877f9cdc0fa8/stl/inc/utility#L930-L949 is "the implementation" =)

We can workaround the issue, but we'd rather not muss our nicely clean implementation. Is there any chance you folks will address this regression?

@CaseyCarter Could you do something like libc++ ?

The issue only affects implements who use type deduction in forward-like
And I think it would be a non-trivial fix.
As best we might be able to not replace the call if the declaration has a deduced type, but you would not get the perf benefits

@zygoloid did that work so maybe he would have a better idea!

As part of treating std::forward_like as a builtin, we no longer instantiate its definition when it's used. This is an important optimization, at least for std::forward and std::move (and likely for std::forward_like once it starts being adopted more heavily). But that means that if the return type is deduced, then we don't have a body to deduce it against.

So, we could change Clang to accept this implementation of forward_like, by instantiating a definition anyway in the case where the return type is deduced. That'd accept the MSVC stdlib implementation, but would mean that you get slower compiles (and potentially larger object files and more debug information depending on whether we manage to avoid emitting anything about the instantiated template specialization or not). Or the MSVC implementation could add an explicit return type, and our optimization could continue to function. Or we could make this case even-more-builtin, and ignore the return type declared in the standard library entirely and work it out for ourselves (either only if it's deduced, or always).

I was hoping for "even-more-builtin" as a best case, but I admit the marginal benefit over the current optimization would be small. In any case, I've found a compromise that I think MSVC and Clang are equally happy with; let's close this issue again.