[PATCH] D111400: [Clang] Implement P2242R3

Corentin Jabot via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Dec 1 07:14:06 PST 2021

cor3ntin added a comment.

In D111400#3164249 <https://reviews.llvm.org/D111400#3164249>, @aaron.ballman wrote:

> In D111400#3088321 <https://reviews.llvm.org/D111400#3088321>, @aaron.ballman wrote:
>> In D111400#3088133 <https://reviews.llvm.org/D111400#3088133>, @hubert.reinterpretcast wrote:
>>> In D111400#3087877 <https://reviews.llvm.org/D111400#3087877>, @aaron.ballman wrote:
>>>> So your concern is that allowing this patch to be used as an extension in older language modes may change the behavior of existing code? Or is your concern more broad than just this patch?
>>> The behaviour of Clang before this patch in older language modes is inconsistent with the specification before P2242R3 (for the template case) in such a way that it could appear that P2242R3 is already implemented for the template case (but not following the usual convention for extensions affecting SFINAE); however, the mechanism by which that occurs might be something other than an implementation of P2242R3.
>>> My concern is that the status quo of the Clang implementation with respect to this area is broken, which in turn makes it possible for this patch to exacerbate the issue by building on top of the brokenness and then making a fix more complicated. At the very least, this patch does not demonstrate that the "extension" does not affect SFINAE.
>>> In other words, my concern is that this patch is necessarily incomplete unless if the situation around the template case is resolved.
>> Thank you for the explanation, that's helpful! I'm sympathetic to not wanting to build on top of an unstable foundation, but I'm also a bit worried that we're asking a lot of @cor3ntin in terms of this PR because it sounds like this is a general request to fix template instantiation before doing more constexpr work (because anything constexpr is generally SFINAE-able). I think we need to fix the template instantiation issues, but I'm also not certain we should gate constexpr work on those fixes.
>> I'd definitely like to hear thoughts from @rsmith on the right way to proceed.
> Pinging @rsmith -- I'd like to unblock @cor3ntin.

If the issue is regarding the support and extension warning in C++20 and older modes, it's something I can address by conserving the status quo in older versions. I did add them to try to be consistent with guidelines I have received in the past
If the ask is a more involved modification of how clang does SFINAE in general, i don't think that i can take that on.
Personally, I do not think going out of our ways to support something that will be broken once people update to c++23 is critical, as it does involve some fairly convoluted code, but i also understand the desire to be as conforming as possible.

  rG LLVM Github Monorepo



More information about the cfe-commits mailing list