https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
--- Comment #14 from Jonathan Wakely ---
Gašper has confirmed that the intention is for it to be SFINAE-friendly, so
declcall would work here (and for [comparisons.general],
[comparisons.three.way], and [range.cmp], although P2434 might make it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
--- Comment #13 from Jonathan Wakely ---
Yes I've read it but it's not clear to me that it's SFINAE-friendly when the
expression resolves to a built-in like that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
--- Comment #12 from Jan Schultke ---
On a language evolution note, https://wg21.link/P2825 would let you detect
whether an equality comparison for enumerations is overloaded by checking
whether
> declcall(E{} == E{})
... is well-formed. If th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
--- Comment #10 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:fab60eaa94b50b1eea84f0d001004c851d4c781b
commit r15-1715-gfab60eaa94b50b1eea84f0d001004c851d4c781b
Author: Jonathan Wakely
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
--- Comment #9 from Jonathan Wakely ---
I'm still not willing to use that though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
--- Comment #8 from Jan Schultke ---
It is a tiny bit pessimistic if it uses std::convertible_to instead of
std::__boolean_testable or what it was called.
I cannot come up with an example that produces a false positive though (which
is crucial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
--- Comment #7 from Jonathan Wakely ---
A better version of the concept sketched above:
template
concept is_sane_enum = std::is_enum_v && (!requires {
[] U>(U (*)(T, T)){}(&operator==);
});
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
--- Comment #6 from Jonathan Wakely ---
(In reply to Jan Schultke from comment #5)
> It would surely miss cases like an operator== with an always-defaulted third
> parameter,
That's not valid, operator== must have two parameters.
> or one wher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
--- Comment #5 from Jan Schultke ---
&operator==(E,E); is not a valid expression, but I understand what you're
trying to do there. Perhaps you can test by converting to a function pointer
bool(*)(E,E).
It would surely miss cases like an operato
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
--- Comment #4 from Jonathan Wakely ---
It's valid for std::byte because we know what equality means for std::byte.
You could maaybe do something like:
template
concept is_sane_enum = is_enum_v && (!requires { &operator==(E,E); });
but I'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
--- Comment #3 from Jonathan Wakely ---
#include
enum E { e };
bool operator==(E, E) { return false; }
int main()
{
E e[1];
return std::equal(e, e+1, e);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
Jan Schultke changed:
What|Removed |Added
CC||janschultke at googlemail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
--- Comment #1 from Jonathan Wakely ---
We can use is_same_v<_ValueType1, byte> instead, which is more efficient to
compile than instantiating __is_byte unconditionally.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
Jonathan Wakely changed:
What|Removed |Added
Keywords||missed-optimization
See Als
17 matches
Mail list logo
