为什么c++ 17的结构化绑定不使用{}?

来自西班牙和美国的国家机构已经提议改回{}语法，因为(P0488R0):

最初使用的"结构化绑定"建议大括号"{}"分隔绑定标识符。那些分隔符更改为中括号"[]"断言它们没有引入任何语法问题。然而，他们竟然介绍属性和lambda的语法歧义。在光的各种建议的修复，它似乎原语法更合适。

因此，仍然有可能最终使用c++ 17的原始语法(我强烈认为大多数用户更喜欢这种语法)。

从这次旅行报告中更新:

分解声明的原始建议使用语法auto {a, b, c};，在上次会议上更改为auto [a, b, c]。这个变化是相当有争议的，一些评论要求将其更改回{}(而其他人则鼓励保留[])。双方都有技术上的争论(一旦你开始允许嵌套分解，[]语法可能会与属性冲突;如果您将概念放入其中并允许使用概念名称而不是auto，那么{}语法可能与统一初始化相冲突，因此最终这主要取决于您的品味。clang实现者确实报告说他们两者都尝试过，并且发现使用[]更容易解决歧义。最后，没有达成一致意见，因此保持现状([]语法)。

这仍在争论中。考虑到[]和{}已经被使用了很多次，很难确定哪种语法最容易混淆。

还存在"最容易混淆"answers"最容易解析"发生冲突的风险。

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

Chandler Carruth对这个问题的回答:youtube .be/430o2HMODj4?t = 15 m50

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

是ok的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++中也有意义，因此会是一个难以解决的歧义，

从{}到[]的变化发生在Jacksonville会议之后，是对会议评论的回应。这在p0144r2中有详细说明，其中指出:"因为它在视觉上与声明相同类型的多个变量的现有语法更不同。"

似乎要求更改{}的原始用法的NB评论在2016年11月的会议上没有增加共识，使[]的用法保持不变。至少在春季会议之前。

关于方括号语法需要说明的一点是，它非常类似于lambda捕获子句，在其中，您不需要指定变量类型，因为auto是隐含的。例如

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

这显然不是完全一样的东西，但是当你把它看作是"通过理解上下文来自动捕获的语法"时，它可以工作:

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