为什么C ++ 17结构化绑定不使用{}？

我在这里find了* C ++结构绑定的原始提案。 它提出了一种轻松绑定多个返回值的方法，即：

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

但是现在我看到每个人都指向C ++ 17 / C ++ 1z的build议语法

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

现在我学到了“列表被写成{like，this}”，那么会出现一个新的列表语法？ 为什么？ 这里的花括号有什么问题？

Answer 1

这仍在争论中。 考虑到[]和{}的用途已经很多，很难确定哪种语法将是最不容易混淆的。

还有“最不容易混淆”和“最容易parsing”的风险将会发生冲突。

Answer 2

来自西class牙和美国的国家机构已经提议改回{}语法，因为（ P0488R0 ）：

“结构化绑定”提案最初使用大括号“{}”来分隔绑定标识符。 这些分隔符被改为括号“[]”，断言他们没有引入任何语法问题。 然而，他们竟然把属性和lambdas引入了句法歧义。 根据各种build议的修复，看起来原来的语法更加合适。

因此，仍然有可能结束为C + + 17原来的语法（我坚信大多数用户偏好）。

---

旅行报告 更新 ：

最初的分解声明提议使用了语法auto {a, b, c}; 这是在上次会议上更改为auto [a, b, c] 。 这个改变是相当有争议的，有几条评论要求将它改回{} （其他人鼓励保留[] ）。 有两方面的技术参数（一旦开始允许嵌套分解， []语法可能与属性发生冲突;如果将Concepts引入混合并允许使用概念名称而不是auto ），则{}语法可能与统一初始化冲突。所以最终主要是品味的问题。 叮铛声的实施者确实报告说他们都尝试了这两种方法，并发现用[]更容易解决的含糊之处。 最后，还没有达成共识，因此现状（ []语法）仍然存在。

Answer 3

从{}到[]的变化发生在jackson维尔之后，是针对该会议的意见而作出的。 这在p0144r2中详细说明 ，其中声明：“因为它声明多个相同types的variables的语法更加直观。

NB似乎要求更改{}的原始用法并没有在2016年11月的会议上达成共识，使得[]使用完好无损。 至less在春季会议之前。

Answer 4

@SebastianWahl只评论一个链接。 我会快速总结链接背后的内容。

Chandler Carruth对这个问题的回答：youtu.be/430o2HMODj4？t = 15m50s

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

与auto是好的。 但是你也可以这样做：

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

所以当你使用{...}这将成为

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

这是不好的 ，因为tuple<int,float,string> {a,b,c}在C ++中也有一个含义，因此将是一个难以解决的模糊问题。

Answer 5

有一点要说的方括号语法是它非常类似于lambda捕获子句，类似地，您不指定variablestypes，因为auto是隐含的。 即

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

这显然不是完全一样的东西，但是当你把它看作“通过理解上下文来进行汽车捕捉的语法”时，它可以工作：

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