Not sure if it would produce a warning about missing return statement even thought unevaluated. If no such warning, that's fine. If there is... maybe call to abort?

Edit: actually I think if is unlikely to have a warning/error here, and if there is, it would be compiler bug.

Yes, I thought about that as well. I looked it up at gcc, and they need a return statement. However, in this codebase, other usages of _Always_false omit a return statement as well. I tested the behavior for cl and clang-cl, and both don't yield any confusing return statement warning. I don't know if it's a bug to yield any warning, but a return statement would be a more robust solution for potentially upcoming compiler changes. I finally decided on this approach because it's more consistent with the existing codebase and has less code to maintain.

It's a shame we don't need a return statement; I was going to suggest return _STD declval<_Ty>(); 😄

I'm mirroring this to an MSVC-internal PR. Please notify me if any further changes are pushed.

Thanks for enforcing this Standard-mandated requirement, and congratulations on your first microsoft/STL commit! 🎉 😸 🚀

This will ship in VS 2022 17.1 Preview 1.