Fixed #425: Show the correct reference type for structured bindings. #451
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
This patch changes the behavior of how the resulting reference type of a binding is determined. Now, the code uses the holding variables type information of a `BindingDecl`. This seems to be consistent with what Clang does. The reference kind of a binding is determined by the declaration of the structured binding. In [dcl.struct.bind] the standard says that the reference type for a binding is an lvalue reference if the initializer is an lvalue and otherwise a rvalue reference. The initializer here donates to the hidden object, referenced as e. WE declare this implicitly by declaring the structured binding. We get an rvalue reference in case we declare the structured binding as a non-reference like this: ``` auto [a, b, c] ``` We get an lvalue reference if the structured binding is declared as this: ``` auto& [a, b, c] ``` In the rvalue case we could profit from move because the contents of the implicitly created object can be moved out. If we have a reference to the original object moving wouldn't be a good ting to do, hence an lvalue reference. `std::get` has overloads for both l- and rvalues and returns the respective reference type for each overload. This behavior is observable thanks to #381 which shows the implicit cast of the hidden object to a rvalue.
Codecov Report
@@ Coverage Diff @@
## main #451 +/- ##
==========================================
- Coverage 98.56% 98.56% -0.01%
==========================================
Files 23 23
Lines 3135 3133 -2
==========================================
- Hits 3090 3088 -2
Misses 45 45
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
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.
This patch changes the behavior of how the resulting reference type of a
binding is determined. Now, the code uses the holding variables
type information of a
BindingDecl. This seems to be consistent withwhat Clang does.
The reference kind of a binding is determined by the declaration of the
structured binding.
In [dcl.struct.bind] the standard says that the reference type for a
binding is an lvalue reference if the initializer is an lvalue and
otherwise a rvalue reference. The initializer here donates to the hidden
object, referenced as e. WE declare this implicitly by declaring the
structured binding.
We get an rvalue reference in case we declare the structured binding as
a non-reference like this:
We get an lvalue reference if the structured binding is declared as
this:
In the rvalue case we could profit from move because the contents of the
implicitly created object can be moved out.
If we have a reference to the original object moving wouldn't be a good
ting to do, hence an lvalue reference.
std::gethas overloads for both l- and rvalues and returns therespective reference type for each overload.
This behavior is observable thanks to #381 which shows the implicit cast
of the hidden object to a rvalue.