Why do C++17 structured bindings not use { }?

Question

I found the original proposal for *C++ structured bindings here. It proposes a way to easily bind multiple return values, i.e.:

auto {a, b} = minmax(data);

But now I see that everyone points to the C++17/C++1z proposal syntax of

auto [a, b] = minmax(data);

Now that I learned "lists are written { like, this }" there comes a new list-syntax? Why? What is the problem with curly braces here?

Answer 1

The change from {} to [] occurred after Jacksonville and was made in response to comments from that meeting. This is detailed in p0144r2, which states: "because it is more visually distinct from the existing syntax for declaring multiple variables of the same type."

It appears that the NB comments requesting a change to the original usage of {} did not increase consensus in the Nov 2016 meetings, leaving the [] usage intact. At least until the Spring meeting.

Answer 2

The National Bodies from Spain and US have proposed to change back to the {} syntax because (P0488R0):

The “structured bindings” proposal originally used braces “{}” to delimit binding identifiers. Those delimiters were changed to brackets “[]” under the assertion that they didn’t introduce any syntactic problem. However, they turned out to introduce syntactic ambiguity with attributes and lambdas. In the light of various suggested fixes, it appears the original syntax is more adequate.

Therefore, there still remains the possibility of ending up having the original syntax for C++17 (which I strongly believe is preferred by most users).

---

Update from this trip report:

The original proposal for decomposition declarations used the syntax auto {a, b, c}; that was changed at the last meeting to auto [a, b, c]. This change was fairly controversial, and several comments asked to change it back to {} (while others encouraged keeping the []). There are technical arguments on both sides (the [] syntax can conflict with attributes once you start allowing nested decompositions; the {} syntax can conflict with uniform initialization if you throw Concepts into the mix and allow using a concept-name instead of auto), so in the end it’s largely a matter of taste. The clang implementers did report that they tried both, and found the ambiguities to be easier to work around with []. In the end, there was no consensus for a change, so the status quo ([] syntax) remains.

Answer 3

@SebastianWahl only commented with a link. I will quickly summarize the content behind the link.

Chandler Carruth's answer to this question: youtu.be/430o2HMODj4?t=15m50s

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

is ok with auto. But you can also do this:

tuple<int,float,string> [a,b,c] = f();

So when you use {...} this would become

tuple<int,float,string> {a,b,c} = f();  //<<< not C++17

which is bad, because the piece tuple<int,float,string> {a,b,c} also has a meaning in C++ and thus would be a difficult ambiguity, difficult to solve.

Answer 4

One thing to be said for the square brackets syntax is that it closely resembles lambda capture clauses, where, similarly, you don't specify the variable type, since auto is implied. I.e.

auto func = [a, b] {}
auto func = [a=1, b=2.0] {}

It's obviously not the exact same thing, but when you think about it as "syntax for auto capturing by making sense of the context," it can work:

auto [a, b] = std::make_pair(1, 2.0);

Answer 5

This is still under debate. It's difficult to be certain which syntax will be least confusing given how many uses there are for [] and {} already.

There's also the risk that "least confusing" and "easiest to parse" will be in conflict.