Why don't C ++ 17 structured bindings use {}?

Question

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

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

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

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

Now that I know that "lists are written {like, this}", does the new list syntax appear? What for? What is the problem with curly braces here?

Answer 1

This is still being discussed. It's hard to be sure which syntax will be the least confusing, given how many of them are used for [] and {} already.

In addition, the risk that the “least confusing” and the “easiest to analyze” will be in conflict.

Answer 2

National authorities from Spain and the United States have suggested returning to the {} syntax because ( P0488R0 ):

The original sentence is "structured bindings" brackets "{}" to delimit binding identifiers. Those separators were replaced with brackets "[]" under which they did not introduce any syntactic problem. However, they turned out to be syntactic ambiguity with attributes and lambdas. In light of the various corrections proposed, it turns out that the original syntax is more adequate.

Thus, it still remains possible to get the original syntax for C ++ 17 (which, I believe, is preferred by most users).

---

Update from this report:

The original sentence used the decomposition syntax auto {a, b, c}; , which was changed at the last meeting to auto [a, b, c] . This change was quite controversial, and several comments asked to change it to {} (while others recommended saving [] ). There are technical arguments on both sides (the syntax [] may conflict with attributes when you start to resolve nested decompositions; the syntax {} may conflict with uniform initialization if you throw Concepts into the mix and allow the use of a conceptual name instead of auto ), therefore, at the end after all, it is pretty much a matter of taste. The clang developers reported that they tried both, and found that ambiguities are easier to work with [] . In the end, there was no consensus on the change, so the status quo ( [] syntax) remains.

Answer 3

@SebastianWahl just commented on the link. I quickly summarize the contents of the link.

Chandler Carrut answers this question: youtu.be/430o2HMODj4?t=15m50s

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

ok with auto . But you can also do this:

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

So when you use {...} , it will become

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

which is bad because the tuple<int,float,string> {a,b,c} piece also makes sense in C ++ and therefore will be a complex ambiguity that is hard to solve.

Answer 4

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

It appears that NB comments requiring a change to the initial use of {} did not reach consensus in the November 2016 meetings, leaving the use of [] unused. At least until Spring.

Answer 5

One thing for the syntax of square brackets is that it is very similar to lambda capture sentences, where in the same way you do not specify the type of the variable, since it means auto. I.e.

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

This is obviously not the same, but when you think of it as automatic capture syntax, understanding the context, it might work:

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