Translate structured bindings - #436

auto [x, y] = pair; should generate the same code as:

auto x = pair.first;
auto y = pair.seond

It's a copy and variables shouldn't be pointers, but rather Value<> on their own.

auto [x, y] = pair; should generate the same code as:

auto x = pair.first;
auto y = pair.seond

It's a copy and variables shouldn't be pointers, but rather Value<> on their own.

That is not the decomposition semantics. It's: copy construct pair, access x and y on the new object.

The generated code should not loose the variable names. It should create the same bindings as in the original code.

The generated code should not loose the variable names. It should create the same bindings as in the original code.

Creating individual variables is wrong. It would call the copy/move constructor of each variable which is not what auto [x, y] = pair does.

auto [x, y] = pair calls only the copy/move constructor of pair.

When the struct has a default copy constructor, you can decompose the clone straight away.
If there's a copy constructor, you can still introduce (Rust) mutable references to each of the fields so the names are preserved.

When the struct has a default copy constructor, you can decompose the clone straight away.

Does not work if the struct has a default copy ctor but the fields have custom copy ctors.

If there's a copy constructor, you can still introduce (Rust) mutable references to each of the fields so the names are preserved.

This breaks the refcount model. If each decomposed variable becomes a &mut then taking the address of the decomposed variable does not work: &mut -> Ptr does not exist.

Creating separate variables is not the C++ semantics.

Creating variables with the same name is important for readability. C++ injects those names on the scope.