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

Question

我在这里找到了*C++结构化绑定的原始提议.它提出了一种轻松绑定多个返回值的方法,即:

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

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

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

既然我已经学会了"列表被编写{like,this}",那么会出现一个新的列表语法？为什么？花括号有什么问题？

Answer 1

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

还存在"最容易混淆"和"最容易解析"的风险.

Answer 2

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

"结构化绑定"提议最初使用大括号"{}"来分隔绑定标识符.这些分隔符被改为括号"[]",断言它们没有引入任何语法问题.然而,他们最终引入了带有属性和lambda的语法歧义.根据各种建议的修复,看起来原始语法更合适.

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

从这次旅行报告更新:

最初的分解声明提议使用auto {a, b, c};了上次会议中更改的语法auto [a, b, c].这一变化颇具争议,有几条评论要求将其改回{}(而其他人则鼓励保留[]).双方都有技术论据([]一旦你开始允许嵌套分解,语法就会与属性发生冲突; {}如果你将Concepts抛入混合并允许使用概念名而不是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

这很糟糕,因为这篇文章tuple<int,float,string> {a,b,c}在C++中也有意义,因此难以解决,难以解决.

Answer 4

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

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