-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Casey's accumulated miscellaneous changes #4900
Merged
Merged
Conversation
This file contains 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
... by making it a `static constexpr` data member instead of a function
Implements `_Tuple_like_impl` as a variable template with four partial specializations instead of as a disjunction of four other variable template specializations. Consequently, each evaluation of `_Tuple_like` causes the compiler to memoize one constexpr variable instead of five.
... since the exposition-only concept doesn't allow for construction of an object of decayed type from a model of *boolean-testable*. Note that the changes in `erase_if(forward_list, pred)` and `erase_if(list, pred)` are the proposed resolution of LWG-4135, which I feel is a no-brainer and can be implemented without comments. I audited for other occurrences after noticing we do the same thing in `forward_list::remove` and `list::remove`. The fold expressions in `<ranges>` are a weird case: they are only problematic when the pack has one element. For zero or more than one elements, the fold expression has type `bool`, but with exactly one element it's a *boolean-testable* that the lambda implicitly decays on return. I think it's a bit more elegant to fix these by adding `|| false` to the fold expressions to make them binary than to explicitly specify the return type of the lambda.
We _can_ `return` an expression with `void` type in a function with return type `void`, but we typically don't do so when the types are concrete.
StephanTLavavej
requested changes
Aug 20, 2024
StephanTLavavej
approved these changes
Aug 21, 2024
I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
Yay various cleanups! 🧹 🎉 🐈⬛ |
34 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
A grab bag of minor changes broken down for quick-and-easy commit-wise review:
<ranges>
: simplifyzip_view::_Size_closure
by making it astatic constexpr
data member instead of a function_Tuple_like
metaprogramming: implements_Tuple_like_impl
as a variable template with four partial specializations instead of as a disjunction of four other variable template specializations. Consequently, each evaluation of_Tuple_like
causes the compiler to memoize one constexpr variable instead of five.erase_if(forward_list, pred)
anderase_if(list, pred)
are the proposed resolution of LWG-4135, which I feel is a no-brainer and can be implemented without comments. I audited for other occurrences after noticing we do the same thing inforward_list::remove
andlist::remove
.The fold expressions in
<ranges>
are a weird case: they are only problematic when the pack has one element. For zero or more than one elements, the fold expression has typebool
, but with exactly one element it's a boolean-testable that the lambda implicitly decays on return. I think it's a bit more elegant to fix these by adding|| false
to the fold expressions to make them binary than to explicitly specify the return type of the lambda.return
incartesian_product_view::_Iterator::iter_swap
. We canreturn
an expression withvoid
type in a function with return typevoid
, but we typically don't do so when the types are concrete.I could be convinced that the boolean-testable change deserves to be in a separate PR with some test coverage.