为什么C17结构化绑定不使用{}？
我在这里找到了最初的*C结构化绑定方案。它提出了一种轻松绑定多个返回值的方法，即：
auto {a, b} = minmax(data);
但现在我看到每个人都指向
auto [a, b] = minmax(data);
现在我学习了“列表是{like，this}编写的”，出现了一种新的列表语法？为什么？这里的花括号有什么问题？
共有3个答案
@SebastianWahl仅用一个链接进行了评论。我会快速总结链接后面的内容。
钱德勒·卡拉斯对这个问题的回答是：youtu。be/430o2HMODj4？t=15m50秒
auto [a,b,c] = f();
可以使用自动。但是您也可以这样做：
tuple<int,float,string> [a,b,c] = f();
所以当你使用{…}
这将成为
tuple<int,float,string> {a,b,c} = f(); //<<< not C++17
这很糟糕，因为块元组
西班牙和美国的国家机构建议重新使用{}语法，因为（P0488R0）：
“结构化绑定”方案最初使用大括号“{}”来定义绑定标识符。这些分隔符被改为括号“[]”，因为它们没有引起任何语法问题。然而，事实证明，他们在属性和lambdas中引入了语法歧义。根据各种建议的修复方案，原来的语法似乎更合适。
因此，仍然有可能最终使用C 17的原始语法（我坚信这是大多数用户更喜欢的）。
这次旅行报告的更新：
最初提出的分解声明使用的语法auto{a， b， c}；在上次会议上被改为auto[a， b， c]。这一更改引起了相当大的争议，一些评论要求将其改回{}（而其他人则鼓励保留[]）。双方都有技术上的争论（一旦你开始允许嵌套分解，[]语法可能会与属性冲突；如果你把概念扔进组合中，允许使用概念名称而不是自动，{}语法可能会与统一初始化冲突），所以最终这在很大程度上是一个品味问题。clang实现者确实报告说他们两种方法都尝试过，并且发现使用[]更容易解决歧义问题。最后，没有就改变达成共识，所以现状（[]语法）仍然存在。
这一点仍在讨论中。考虑到[]和{}已经有很多用法，很难确定哪种语法最容易混淆。
“最不容易混淆”和“最容易解析”也存在冲突的风险。
-
c 17引入了结构化绑定。它们能够声明从元组或结构初始化的多个变量。 此代码使用编译器进行编译。 如果我没有用声明变量，我会得到错误 错误：lambda表达式[d2，i2]的预期主体=元组； 我使用了clang version 4.0.0和编译选项-std=c 1z。 我可以将现有变量分配给结构化绑定吗？我需要使用？
-
我正在学习结构化绑定声明。我的理解是，
-
我一直在编写一组类来允许一个简单的类似python的-函数。下面的片段（几乎）和预期的一样工作。然而，两个变量和不是。 我一直在使用gcc 7.3.0。以下是MCVE：
-
简短版本： 我希望能够将结构转换为元组。至少是那种类型。在下面的代码中，convertToTuple函数不起作用，因为可变参数不能用于结构化绑定（据我所知）。关键是：自动 基本上，我需要的是一种将自定义结构的类型转换为元组的方法，元组包含结构中的所有类型。例如： 具体问题： 我想创建一个模板函数，它将一个类型或一个类型列表作为模板参数，并生成一个纹理列表，每个纹理包含一个项目。另一个函数可以对纹理
-
为什么结构化绑定是通过一个唯一命名的变量和所有模糊的“name is bind to”语言定义的？ 我个人认为结构化绑定的工作原理如下。给定一个结构： 以下内容： 大致相当于 数组和元组的等价展开式。但显然，这太简单了，而且有所有这些模糊的特殊语言用来描述需要发生的事情。 很明显，我遗漏了一些东西，但确切的情况是什么，一个定义良好的扩展，比如说，折叠表达式，在标准语言中读起来要简单得多？ 似乎结构
-
据我所知，C 17中结构化绑定引入的标识符实际上是对某些“隐藏”变量的引用。以至于 相当于 但是，如果我打印出