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

时间:2016-10-30 19:57:01

标签: c++ c++17 structured-bindings

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

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

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

的C ++ 17 / C ++ 1z提议语法
auto [a, b] = minmax(data);

现在我学会了#34;列表是{like,this}"有一个新的列表语法?为什么?花括号有什么问题?

5 个答案:

答案 0 :(得分:21)

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

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

答案 1 :(得分:21)

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

  

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

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

来自此trip report

更新

  

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

答案 2 :(得分:13)

@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 ++中也有意义,因此难以解决,难以解决。

答案 3 :(得分:10)

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

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

答案 4 :(得分:3)

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

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

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

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