forked from llvm/llvm-project
-
Notifications
You must be signed in to change notification settings - Fork 2
[libc++] Make expected
trivially assignable whenever possible
#47
New 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
Open
Quuxplusone
wants to merge
1
commit into
main
Choose a base branch
from
pr47-trivial-expected
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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.
Is it intended not to consider
is_trivially_destructible_v
? (See also LWG4026 and P0602R4 which considered trivial destructibility.)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.
Today,
is_trivially_copy_constructible_v<T>
logically impliesis_trivially_destructible_v<T>
. (Godbolt.) There is some controversy about the desirability of this fact, but it's still a fact. So my personal view is that we shouldn't add redundant conditions that won't ever affect the conjunction's result. But I know that "reasonable people disagree," and I certainly wouldn't object if this were upstreamed with the redundant condition added.Actually, in Hagenberg this very question came up during discussion of P2786's
is_nothrow_relocatable
, where the version approved in plenary has ([meta.unary.prop]):Today,
is_nothrow_move_constructible_v<remove_all_extents_t<T>>
logically impliesis_nothrow_destructible_v<remove_all_extents_t<T>>
, so personally I wouldn't have written it this way. But a vocal contingent on LWG did want the redundant condition, and since it has no effect there's no physical reason to oppose adding it, so, it got added.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.
Oh, I think this is arguable, as LWG2116 and LWG2827 aren't resolved yet.
I guess it's worthwhile to explicitly specify that multiple
is_trivially_*
implyis_trivially_destructible_v
(or at least having a trivial non-deleted destructor), as we can hardly do anything special for a trivially-meowable but not trivially destructible class.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.
Sure, but LWG did vote in 2022 to close them as NAD/evolutionary (as shown in the minutes for LWG2116); I'm not sure why they haven't been actually closed in the issue system yet.
The evolutionary question is indeed argued. But I don't think such a change stands much chance precisely because there's already code just like the code I wrote, out there in the wild, which would quietly change semantics if we changed the meaning of these traits. In fact, notice that there exists a paper discussing why we might want to change the semantics of these traits (P2842R0, cplusplus/papers#1547 ), and its proposed resolution (§7 and §9) is literally to ratify LWG's position and close the issues as NAD — after all that it's still not proposing that we should change the traits!