[[maybe_unused]] в перечислителе

Глядя на спецификацию [[maybe_unused]], она заявляет:

Появляется в объявлении класса, typedef, переменная, нестатический член данных, функция, перечисление или перечислитель. Если компилятор выдает предупреждения о неиспользуемых объектах, это предупреждение подавляется для любой объявленной сущности Maybe_unused.

Как говорится в перечислителе, я ожидаю, что у него будет прецедент. Как единственное, что я мог придумать, это предупреждение -Wswitch, я попробовал его с Clang, GCC и MSVC.

enum A
{
    B,
    C [[maybe_unused]]
};

void f(A a)
{
    switch (a)
    {
        case B: break;
    }
}

Все 3 компилятора дают мне следующие предупреждения:

<source>:9:13: warning: enumeration value 'C' not handled in switch [-Wswitch]
    switch (a)
            ^

Живой код

Является ли это допустимым прецедентом для использования этого атрибута, есть ли другие варианты использования для добавления атрибута в этом месте или это просто бесполезное дополнение?

Ответ 1

Ошибка была зарегистрирована для Clang и помечена как исправленная: https://bugs.llvm.org/show_bug.cgi?id=36231

Это, кажется, подтверждает, что значение перечисления может отсутствовать в переключателе без предупреждения в случае, если оно помечено [[Maybe_unused]]

Ответ 2

Цель этого атрибута состоит в том, чтобы объявить, что объект никогда не может быть использован, и если это произойдет, реализация не должна беспокоить вас предупреждением о том, что где-то, например, вы можете использовать неправильный объект.

Операторы

switch - совсем другое дело: не обрабатывать перечислитель проблематично, даже если перечислитель никогда не используется в этом TU; это указывает на логический пробел в вашей программе. Что делать, если эта функция имеет внешнюю связь, а кто-то еще вызывает ее с этим перечислителем?

Короче говоря, даже в TU, в которых мы пометили перечислитель как потенциально неиспользуемый (что кажется бессмысленным, потому что в области пространства имен они часто бывают), охватывая его в вашей программной логике, все еще очень рекомендуется (и Clang совершенно прав в предоставлении вам этого совета).