[Bug c++/102012] GCC accepts any non-bool atomic constraint type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102012 Patrick Palka changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #6 from Patrick Palka --- closing as invalid then
[Bug c++/102012] GCC accepts any non-bool atomic constraint type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102012 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #5 from Jason Merrill --- I agree with Patrick; https://eel.is/c++draft/temp.names#9 says how to evaluate a concept-id, it does not say that a concept-id is always evaluated. The note even talks about one instance of a concept-id not being evaluated in an unevaluated operand.
[Bug c++/102012] GCC accepts any non-bool atomic constraint type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102012 --- Comment #4 from Patrick Palka --- (In reply to 康桓瑋 from comment #3) > (In reply to Patrick Palka from comment #1) > > Hmm, I think this might actually be well-formed according to [temp.names]/9. > > I don't see why we'd need to check satisfaction of a concept-id inside > > decltype if its type is already prescribed to be bool. > > "The standard requires MSVC/Clang's behavior of erroring out." from > https://stackoverflow.com/a/68910627/11638718. Yes, evaluation of the concept-id should produce an error during satisfaction due to the non-bool constraint. But why should we evaluate a concept-id inside decltype in the first place, when the type of a concept-id is always prescribed to be bool?
[Bug c++/102012] GCC accepts any non-bool atomic constraint type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102012 --- Comment #3 from 康桓瑋 --- (In reply to Patrick Palka from comment #1) > Hmm, I think this might actually be well-formed according to [temp.names]/9. > I don't see why we'd need to check satisfaction of a concept-id inside > decltype if its type is already prescribed to be bool. "The standard requires MSVC/Clang's behavior of erroring out." from https://stackoverflow.com/a/68910627/11638718.
[Bug c++/102012] GCC accepts any non-bool atomic constraint type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102012
--- Comment #2 from 康桓瑋 ---
(In reply to Patrick Palka from comment #1)
> Hmm, I think this might actually be well-formed according to [temp.names]/9.
> I don't see why we'd need to check satisfaction of a concept-id inside
> decltype if its type is already prescribed to be bool.
You are right..
template
concept C = T{}.foo();
decltype(C) x = 0;
https://godbolt.org/z/zr5qhfGPY
[Bug c++/102012] GCC accepts any non-bool atomic constraint type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102012 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Hmm, I think this might actually be well-formed according to [temp.names]/9. I don't see why we'd need to check satisfaction of a concept-id inside decltype if its type is already prescribed to be bool.
[Bug c++/102012] GCC accepts any non-bool atomic constraint type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102012 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-08-23 Status|UNCONFIRMED |NEW Blocks||67491 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
