И я не собираюсь возлагать на плечи компилятора тяжёлую работу по автодетекту. Вместо этого я могу оставить ему хинт в виде noexcept.

Ну, определить в стандарте, что move-конструктор всегда noexcept?

Я боюсь, что это не так просто, как вы думаете.

т.е. если мув провалится по любой причине, сразу исключение в колено кидать? :)

чтобы иметь возможность передать свои знания о контракте коллеге или компилятору

Тогда не работает правило "нельзя бросать исключения в move-конструкторе" и я все ещё не понимаю зачем noexcept в шаблонах)

👍 лучше и не сказать

Какие знания в шаблонах? Любой человек запихнувший в шаблон тип без noexcept все сломает)

Если очень надо - вешаем static_assert

Когда ты пишешь шаблон, ты не можешь дать никаких гарантий никому

Потому что ты не знаешь, во что его будут инстанцировать

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

тогда были throw()

поэтому не надо говорить, что об исключениях не думали

которым никто не пользовался

Настанет день - и сломает) И вот тогда придется убрать noexcept) Привет проблемы с тем, что кто-то положился на noexcept)

канешна никто не пользовался!

пользовались, почему нет?

Идея описана в самом конце: не применять P1656 "Throws: Nothing" should be noexcept до тех пор, пока не появятся концепты

Иначе - концепты теряют часть смысла, корпоративные стандартные библиотеки перестают удовлетворять стандатту, мы поощряем плохие практики и провоцируем баги

1. Чем так плохо, что будут non confirming библиотеки?
2. Если я пишу noexcept neutral code, отсутствие noexcept на стандартной библиотеке заставляет меня либо писать в документации, что не смотря на то что моя функция не кидает пока вы не используете кидающие контракты все в порядке, либо писать unconditional noexcept.

А можно ли сделать так, чтобы контракты влияли на сигнатуру функции? То есть снимали бы noexept, если используются исключения для сигнализации нарушения контракта?