我找到了* C ++结构化绑定here的原始提案。它提出了一种容易绑定多个返回值的方法,即:
auto {a, b} = minmax(data);
但现在我看到每个人都指向
的C ++ 17 / C ++ 1z提议语法auto [a, b] = minmax(data);
现在我学会了#34;列表是{like,this}"有一个新的列表语法?为什么?花括号有什么问题?
答案 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);