Question

我找到了* C ++结构化绑定here的原始提案。它提出了一种容易绑定多个返回值的方法，即：

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

但现在我看到每个人都指向

的C ++ 17 / C ++ 1z提议语法

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

现在我学会了＃34;列表是{like，this}＆＃34;有一个新的列表语法？为什么？花括号有什么问题？

Answer 1

这仍然存在争议。鉴于[]和{}已有多少用途，很难确定哪种语法最不容易混淆。

还存在“最容易混淆”和“最容易解析”的风险。

Answer 2

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

最初使用的“结构化绑定”提案大括号“{}”来分隔绑定标识符。那些分隔符改为括号“[]”下的括号断言他们没有引入任何句法问题。然而，他们原来是介绍具有属性和lambda的语法歧义。在各种建议修复的亮点，它出现了原始语法更合适。

因此，仍然有可能最终拥有C ++ 17的原始语法（我坚信大多数用户都喜欢这种语法）。

来自此trip report的

更新：

分解声明的原始提议使用在上次会议中更改为auto {a, b, c};的语法auto [a, b, c]。这一变化颇具争议，有几条评论要求将其更改回{}（其他人鼓励保留[]）。双方都有技术论据（一旦你开始允许嵌套分解，[]语法可能会与属性冲突;如果你将Concepts放入混合并允许使用一个概念，{}语法可能会与统一初始化冲突-name而不是auto），所以最后它主要是品味问题。 clang实现者确实报告说他们都尝试过这两种方法，并且发现使用[]更容易解决这些含糊之处。最后，对于更改没有达成共识，因此现状（[]语法）仍然存在。

Answer 3

@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

bad ，因为作品tuple<int,float,string> {a,b,c}在C ++中也有意义，因此难以解决，难以解决。

Answer 4

从{}到[]的变化发生在杰克逊维尔之后，是为了回应该会议的评论。这在p0144r2中有详细说明，其中指出：＆＃34;因为它在声明上与现有语法不同，用于声明相同类型的多个变量。＆＃34;

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

Answer 5

方括号语法要说的一点是它非常类似于lambda捕获子句，类似地，你没有指定变量类型，因为隐含了 auto 。即。

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

显然不是完全相同的东西，但当你把它看作“通过理解上下文来自动捕获的语法”时，它可以工作：

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

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

5 个答案: