Structured binding to replace std::tie abuse

Question

In reading this summary of the c++17 final features I was a bit surprised by the section on structured bindings (emphasis mine):

structured bindings

Until now, there was a known trick to abuse std::tie to assign a tuple or pair to different variables directly, instead of having to deal with the result type manually. This was a hack, and also the variables had to exist, now you can declare the variables and initialize them in one line:

auto [a , b , c] = getvalues();

The braces are needed, getvalues returns a tuple. std::pair is not mentioned in the proposal, so its unclear if this works with pair, which is returned by the STL in some insert methods.

I am assuming they refer to this kind of usage of std::tie

int a,b,c;
std::tie(a,b,c) = std::make_tuple(1,2,3);

which I believed to be a recommended practice.

Can someone offer an explanation as to why they are referring to above example as a hack?

Answer 1

std::tie in itself has another functionality.

It was meant for creating a tuple with references to variables

Creates a tuple of lvalue references to its arguments or instances of std::ignore.

This is useful for creating on-the-fly tuples without having to copy the variables because they are references. I just take the example from cppreference for a usecase.

bool operator<(const S& rhs) const
{
    // compares n to rhs.n,
    // then s to rhs.s,
    // then d to rhs.d
    return std::tie(n, s, d) < std::tie(rhs.n, rhs.s, rhs.d);
}

Here tuples are created but they don't copy the variables but have references.

Now because they hold references you could "hack" it to do something like this

int a,b,c;
std::tie(a,b,c) = std::make_tuple(1,2,3);

It assigns the values of the returned tuple to the one with the references in itself.

This is even on cpprefence just mentioned as a "note"

std::tie may be used to unpack a std::pair because std::tuple has a converting assignment from pairs

So in c++11 was not really an official way to directly assign values but std::tie can be used as this but maybe was never intended to be used that way.

So they introduced the new "structured binding".

Whether std::tie was meant to be used that way or is a "hack" may be personal opinion, I guess the people who introduced std::tie know best for this. But considering how structured binding kind of replaces std::tie in that instance, they came up with a solution they think is better.

Answer 2

I can put it simply like that:

In a language where functions can return just one variable

int a,b,c;
std::tie(a,b,c) = function_returning_multiple_values();

is a hack for:

auto [a, b, c] = function_returning_multiple_values();

just as in the hypothetical world where C++ would allow just one parameter for functions

int p1, p2, p3;
p1 = ...;
p2 = ...;
p3 = ...;

function_taking_multiple_params(std::tie_params(p1, p2, p3));

would be a hack for:

function_taking_multiple_params(p1, p2, p3)

---

You are so accustomed with the C++ restriction that a function can return at most one object, but in fact it is just an artificial language restriction, just as a restriction to accept at most one parameter would be an artificial language restriction.

The std::tie is a library hack for a missing language feature. And it has some drawbacks:

• the variables need be declared beforehand
• the variable types must be declared explicitly
• Inefficient or can't be used with types that are not default constructible

---

Are structured bindings everything that they could have been? No, but for the most cases they are everything we need.

What is missing?

• Explicit type for some elements: e.g.:

auto [a, std::string b, c] = foo();

where a and c have the type deduced and b is explicit "std::string"

• Nesting. E.g.:

auto [a, [b1, b2], c] = foo();

where the second returned object from foo is a tuple like object.

• Language feature at the return site (bypassing std::tuple all together):

auto foo() -> [int, int]

instead of

auto foo() -> std::tuple<int, int>

• Named return objects

auto foo() -> [int& key, int& value]

... well... wouldn't that be nice

• and combine that with... - get ready for a cool new name - Generalized return initialization:

auto minmax_element(It begin, It end) -> [It min_it, It max_it];

auto [min = *min_it, max = *max_it] = minmax_element(...);