Question

具有模式匹配的函数式语言（有时是？）有可能忽略一些绑定值，但是使用C ++ 17结构化绑定似乎没有办法做到这一点（std::ignore with structured bindings?）。建议是使用虚拟名称，但随后我们会收到有关未使用变量的警告。

使用clang和gcc的最新头部，这可以做到预期的事情，这很好用，很有用，

[[maybe_unused]] auto x =4 ; // fine, no warning
[[maybe_unused]] auto [a,dummyb,dummyc] = std::tuple<int,int,float>(1,1,1.0f);

但我也希望这会奏效：

auto [g,[[maybe_unused]]dummyh,[[maybe_unused]]dymmyi] =
      std::tuple<int,int,float>(1,1,1.0f);

是否有特定原因attributes不能在这里使用？（在标准和技术上）。 gcc或clang都不接受这个。

编辑，收集支持状态:(感谢godbolt/compiler explorer）。它可以按预期工作（也可能更早）：

gcc 8.0 trunk（g ++ 8.0.0 20171015 experimental）
clang 4.0.0
icc 18（未经测试，根据specs）

MSVC 17.3.5（和Visual Studio GUI），允许属性，但它不适用于结构化绑定。 bug report

Answer 1

在结构绑定文件中：

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0144r2.pdf

他们讨论了他们的推理：

3.8是否有办法明确忽略组件？

动机是将编译器警告与未使用的名称联系起来。

我们认为答案应该是“还没有。”这不是出于使用的动机   案例（沉默编译器警告是一种动机，但它不是一个   用例本身，最好留下，直到我们可以重新审视这个   这应该是更一般的模式匹配提案的上下文   作为特例失败了。

与std :: tie的对称性建议使用   像std :: ignore：
之类的东西
   tuple<T1,T2,T3> f(); 
   auto [x, std::ignore, z] = f(); // NOT proposed: ignore second element 
然而，这感觉很尴尬。

预测语言中的模式匹配   可以建议像_或*这样的通配符，但因为我们还没有   模式匹配现在选择我们知道的语法还为时过早   兼容。这是一个纯粹的扩展，可以等待考虑   与模式匹配。

虽然这没有明确地解决[[maybe_unused]]，但我认为推理可能是相同的。停止编译器警告不是一个用例。

Answer 2

作为对CWG 2360的一项决议，该标准的工作草案采用了以下措词（[dcl.attr.unused]）：

该属性可以应用于类的声明， typedef-name ，变量（包括结构化绑定声明），非静态数据成员，函数，枚举或枚举。



对于标记为maybe_unused的实体，实现不应发出警告，说明该实体或其结构化绑定（如果有）已使用或未使用。对于未标记为maybe_unused的结构化绑定声明，除非所有结构化绑定都未使用，否则实现不应发出这样的警告。

以前没有明确提到结构化的绑定声明。

与[[maybe_unused]]结构化绑定

2 个答案: