Почему std :: move не [[nodiscard]] в C ++ 20?

Question

Я недавно прочитал о [[nodiscard]] в C ++ 17, и, насколько я понимаю, это новая функция (дизайн по контракту?), Которая заставляет вас использовать возвращаемое значение.Это имеет смысл для спорных функций, таких как std::launder (nodiscard начиная с C ++ 20), но мне интересно, почему std::move не определено так же, как в C ++ 17/20.Знаете ли вы вескую причину или это потому, что C ++ 20 еще не завершен?

Answer 1

Команда стандартных библиотек MSVC пошла дальше и добавила несколько тысяч экземпляров [[nodiscard]] с версии VS 2017 15.6 и сообщила о безумном успехе с ней (как с точки зрения обнаружения множества ошибок, так и отсутствия жалоб пользователей). Критерии, которые они описали, были примерно:

1. Чистые наблюдатели, например vector::size(), vector::empty и даже std::count_if()
2. Вещи, которые приобретают сырые ресурсы, например, allocate()
3. Функции, в которых исключение возвращаемого значения может привести к неправильному коду, например, std::remove()

MSVC помечает std::move() и std::forward() как [[nodiscard]] в соответствии с этими критериями.

Хотя это официально не аннотировано как таковое в стандарте, похоже, оно дает очевидную выгоду для пользователя, и это больше вопрос изготовления такой бумаги, чтобы пометить все правильные вещи [[nodiscard]] (опять же, несколько тысяч экземпляров из MSVC) и применять их - это не сложная работа как таковая, но объем большой. В то же время, может быть, подтолкнуть вашего любимого поставщика стандартной библиотеки и попросить их [[nodiscard]] много вещей?

Answer 2

AFAIK P0600R1 - единственное предложение по добавлению [[nodiscard]] в стандартную библиотеку, которая была применена к C ++ 20.Из этой статьи:

Мы предлагаем консервативный подход:

[...]

Не следует добавлять, когда:

• [...]
• не использовать возвращаемое значение не имеет смысла, но не повредит и обычно не является ошибкой
• [...]

Итак, [[nodiscard]] не должен сигнализировать о плохом коде, если это

• [...]
• не повреждает и, вероятно, не подразумевалось изменение состояния, которое не 'это может произойти

Так что причина в том, что стандартная библиотека использует консервативный подход, а более агрессивный еще не предложен.