Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[libc++] Implement P3379R0 Constrain
std::expected
equality operators #135759New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[libc++] Implement P3379R0 Constrain
std::expected
equality operators #135759Changes from all commits
a8aacd4
f69fb88
72e6101
a428d4a
7754d35
3e0f49e
860ad25
fe542c0
912176f
e94e3c9
7b69015
58cfc99
300eefa
8b966b6
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is the reason why you don't use
convertible_to<bool>
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've told the reason in #117664 (comment).
convertible_to
requires both implicit and explicit convertibility, where the standard wording only requires the latter. Moreover, due to explicit object member functions and CWG2813, we can invent a class whose prvalue is implicitly convertible tobool
but xvalue isn't.Example (Godbolt link):
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say it is very contrived and I would hardly believe the standard is designed to be in this form. IMO, implicit conversion should be a superset of explicit conversion. Implicitly conversion should imply explicit conversion.
Having something is implicitly convertible to, but not explicitly convertible to , is , just , a foot gun.
This similar to non-const vs const. The example above is in the same spirit of having
void f(const Foo&);
void f(Foo&) = delete;
I would say, why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's intended to allow such a return type. However, the core language rules "accidentally" permits such a weird return type when there's no additional constraints/
static_assert
's.IMO, P3379R0 and P2944R3 (for
optional
,variant
, andexpected
) should only add constraints that reflects the "mandates" in thereturn
statements. It seems that the original intent of operators was that natural mandates in thereturn
statements should work for these operators, and thus no additionalstatic_assert
would be necessary.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, even when there's no issue with explicit conversion, the prvalue VS xvalue problem still blocks use of
convertible_to
. Godbolt link.