structured bindings: when something looks like a reference and behaves similarly to a reference, but it's not a reference
Yesterday I've seen an interesting question here on SO about structured binding.
We can sum up it as it follows. Consider the example code below:
#include <tuple>
#include <type_traits>
int main() {
auto tup = std::make_tuple(1, 2);
auto & [ a, b ] = tup;
// the following line won't compile for a isn't a reference
// static_assert(std::is_reference_v<decltype(a)>);
}
In this case decltype(a)
is int
(probably) because of this bullet (working draft):
if
e
is an unparenthesized id-expression naming a structured binding [...],decltype(e)
is the referenced type as given in the specification of the structured binding declaration
Here is a snippet on wandbox provided by @Curious in the comments for those that are interested. It shows that actually a
isn't a reference, nothing more.
So far so good for the original question, OP asked why it was int
instead of int &
and the standard says that looked like an acceptable answer.
Anyway, I'd like to know why the committee decided so. At the end of the day, a
refers to an element in the tuple and I can modify that element through a
. In other terms, the declaration of a
looks like the one of a reference, it behaves similarly to a reference but it's not a reference.
I can live with this, but I'd like to know what are the reasons behind that. Why decltype(a)
cannot be simply int &
? Is there a meaningful reason that a profane can understand?
I wrote this yesterday:
decltype(x)
, wherex
is a structured binding, names the referenced type of that structured binding. In the tuple-like case, this is the type returned bystd::tuple_element
, which may not be a reference even though the structured binding itself is in fact always a reference in this case. This effectively emulates the behavior of binding to a struct whose non-static data members have the types returned bytuple_element
, with the referenceness of the binding itself being a mere implementation detail.