简体   繁体   English

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

[英]Why do C++17 structured bindings not use { }?

I found the original proposal for *C++ structured bindings here . 我在这里找到了* C ++结构化绑定的原始提议。 It proposes a way to easily bind multiple return values, ie: 它提出了一种轻松绑定多个返回值的方法,即:

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

But now I see that everyone points to the C++17/C++1z proposal syntax of 但现在我看到每个人都指向C ++ 17 / C ++ 1z提议语法

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

Now that I learned "lists are written { like, this }" there comes a new list-syntax? 既然我已经学会了“列表被编写{like,this}”,那么会出现一个新的列表语法? Why? 为什么? What is the problem with curly braces here? 花括号有什么问题?

This is still under debate. 这仍然存在争议。 It's difficult to be certain which syntax will be least confusing given how many uses there are for [] and {} already. 考虑到[]和{}已有多少用途,很难确定哪种语法最不容易混淆。

There's also the risk that "least confusing" and "easiest to parse" will be in conflict. 还存在“最容易混淆”和“最容易解析”的风险。

The National Bodies from Spain and US have proposed to change back to the {} syntax because ( P0488R0 ): 来自西班牙和美国的国家机构已提议改回{}语法,因为( P0488R0 ):

The “structured bindings” proposal originally used braces “{}” to delimit binding identifiers. “结构化绑定”提议最初使用大括号“{}”来分隔绑定标识符。 Those delimiters were changed to brackets “[]” under the assertion that they didn't introduce any syntactic problem. 这些分隔符被改为括号“[]”,断言它们没有引入任何语法问题。 However, they turned out to introduce syntactic ambiguity with attributes and lambdas. 然而,他们最终引入了带有属性和lambda的语法歧义。 In the light of various suggested fixes, it appears the original syntax is more adequate. 根据各种建议的修复,看起来原始语法更合适。

Therefore, there still remains the possibility of ending up having the original syntax for C++17 (which I strongly believe is preferred by most users). 因此,仍然有可能最终得到C ++ 17的原始语法(我坚信大多数用户都喜欢这种语法)。


Update from this trip report : 从这次旅行报告 更新

The original proposal for decomposition declarations used the syntax auto {a, b, c}; 分解声明的原始提议使用语法auto {a, b, c}; that was changed at the last meeting to auto [a, b, c] . 在上次会议中更改为auto [a, b, c] This change was fairly controversial, and several comments asked to change it back to {} (while others encouraged keeping the [] ). 这一变化颇具争议,有几条评论要求将其改回{} (而其他人则鼓励保留[] )。 There are technical arguments on both sides (the [] syntax can conflict with attributes once you start allowing nested decompositions; the {} syntax can conflict with uniform initialization if you throw Concepts into the mix and allow using a concept-name instead of auto ), so in the end it's largely a matter of taste. 双方都有技术论据(一旦你开始允许嵌套分解, []语法就会与属性发生冲突;如果你将Concepts抛入混合并允许使用概念名而不是auto ,那么{}语法可能会与统一初始化发生冲突,所以最后它主要是品味问题。 The clang implementers did report that they tried both, and found the ambiguities to be easier to work around with [] . clang实现者确实报告说他们都尝试过这两种方法,并发现使用[]可以更容易地解决这些问题。 In the end, there was no consensus for a change, so the status quo ( [] syntax) remains. 最后,对于更改没有达成共识,因此现状( []语法)仍然存在。

@SebastianWahl only commented with a link. @SebastianWahl只评论了一个链接。 I will quickly summarize the content behind the link. 我将快速总结链接背后的内容。

Chandler Carruth's answer to this question: youtu.be/430o2HMODj4?t=15m50s Chandler Carruth对这个问题的回答:youtu.be/430o2HMODj4?t=15m50s

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

is ok with auto . auto But you can also do this: 但你也可以这样做:

tuple<int,float,string> [a,b,c] = f();

So when you use {...} this would become 所以当你使用{...}这会变成

tuple<int,float,string> {a,b,c} = f();  //<<< not C++17

which is bad , because the piece tuple<int,float,string> {a,b,c} also has a meaning in C++ and thus would be a difficult ambiguity, difficult to solve. 这是坏事 ,因为片段tuple<int,float,string> {a,b,c}在C ++中也有意义,因此难以解决,难以解决。

The change from {} to [] occurred after Jacksonville and was made in response to comments from that meeting. 从{}到[]的变化发生在杰克逊维尔之后,是为了回应该会议的评论。 This is detailed in p0144r2 , which states: "because it is more visually distinct from the existing syntax for declaring multiple variables of the same type." 这在p0144r2中有详细说明 ,其中指出:“因为它在声明上与现有语法的区别在于声明同一类型的多个变量。”

It appears that the NB comments requesting a change to the original usage of {} did not increase consensus in the Nov 2016 meetings, leaving the [] usage intact. 似乎要求更改{}原始用法的NB评论未在2016年11月的会议中增加共识,使[]用法保持不变。 At least until the Spring meeting. 至少到春季会议。

One thing to be said for the square brackets syntax is that it closely resembles lambda capture clauses, where, similarly, you don't specify the variable type, since auto is implied. 方括号语法要说的一点是它非常类似于lambda捕获子句,类似地,你没有指定变量类型,因为暗示了auto Ie

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

It's obviously not the exact same thing, but when you think about it as "syntax for auto capturing by making sense of the context," it can work: 它显然不是完全相同的东西,但是当你把它看作“通过理解上下文来自动捕获的语法”时,它可以工作:

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

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 C++17 中的初始化列表和结构化绑定推导歧义 - Initializer list and structured bindings deduction ambiguity in C++17 结构化绑定在C ++ 17中引入的标识符类型有哪些? - What are the types of identifiers introduced by structured bindings in C++17? 如何在 vscode 中禁用 C++17 可用的结构化绑定的警告? - How to disable warning for structured bindings available with C++17 in vscode? 在Visual Studio 2017中使用C ++ 17``结构化绑定&#39;&#39;功能 - Using c++17 'structured bindings' feature in visual studio 2017 创建模板以在 C++11 中迭代 map,类似于 C++17 的结构化绑定 - Create a template to iterate map in C++11 like C++17's structured bindings 具有不可移动类型的多个返回值(结构化绑定)和C ++中保证的RVO 17 - Multiple return values (structured bindings) with unmovable types and guaranteed RVO in C++17 通过类比理解C ++ 17中的结构化绑定 - Understand structured binding in C++17 by analogy 为什么在 C++17 中使用 std::make_unique? - Why use std::make_unique in C++17? 为什么 ISO c++17 不允许在条件中使用结构化绑定声明? - Why doesn't ISO c++17 permit a structured binding declaration in a condition? for vs if vs while中的C ++ 17结构化绑定声明 - C++17 structured binding declaration in for vs if vs while?
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM