structured bindings: when something looks like a reference and behaves similarly to a reference, but it's not a reference

Question

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:

#inclu         


        

Answer 1

I wrote this yesterday:

decltype(x), where x is a structured binding, names the referenced type of that structured binding. In the tuple-like case, this is the type returned by std::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 by tuple_element, with the referenceness of the binding itself being a mere implementation detail.

Answer 2

This topic has been covered before (look in the structured-bindings tag) and the behavior you're talking about is even addressed in the second answer. However, the rationale is spelled out in p0144r2 section 3.5:

Should the syntax be extended to allow const/&-qualifying individual names' types?

For example:

auto [&x, const y, const& z] = f(); // NOT proposed

We think the answer should be no. This is a simple feature to store a value and bind names to its components, not to declare multiple variables. Allowing such qualification would be feature creep, extending the feature to be something different, namely a way to declare multiple variables.

If we do want to declare multiple variables, we already have a way to spell it:

 auto val    = f();
 T& x        = get<0>(val);
 T2 const y  = get<1>(val);
 T3 const& z = get<2>(val);