в стандарте оно вот здесь

книга "Решение задач на современном C++" нужна кому-нибудь? на русском.  pdf

Бансила? 2020 год?(второе издание)?

Бансила, но она 19г а не 20

он просто уже и с 20-м стандартом выпустил книжку аналогичную (извините за офтоп).

кинь всем в канал с книгами

админам напиши

Предположим, есть такой код, в котором foo1 и foo2 являются пользовательскими функциями, а всё остальное — библиотечное. Сейчас код не компилируется из-за того, что пользователь написал sfinae-unfriendly foo1

Способы заставить код компилироваться:
1) пользователь просто убирает вычисление noexcept
2) пользователь пишет foo1 правильно
3) мы со стороны библиотеки переписываем bar так, чтобы исключить вызов foo1 при возможности вызвать foo2

Должен ли я как разработчик библиотеки предпочесть третий вариант решения? Или же написание корректного кода должно быть ответственностью пользователя? Ведь третье решение скрывает проблему, а не решает её

я правильно понимаю, что foo1 вызывается не потому, что bar_impl(double) выбран, а как часть процесса разрешения перегрузки/инстанциации шаблона?

Да, именно так

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

третий вариант выглядит как эмуляция SFINAE вне контекста перегрузки. это, наверное, может иметь смысл в каких-то случаях, но не проще ли тогда на нормальную перегрузку перейти?

с другой стороны, есть впечатление, что в текущей реализации SFINAE это именно то поведение, которого хочется

Дело в том, что проблема пользователя не в вычислении noexcept, а в том, что он написал функцию, которая вне sfinae-контекста делает что-то с заранее неизвестным типом, и это стреляет в ногу таким странным образом.

Более правильным решением со стороны пользователя было бы сделать вызов foo1 ill-formed в sfinae-контексте (например, взять второй мой вариант решения или повесить концепт на Fn). Т.е. правильным контрактом было бы требовать от пользователя предоставлять sfinae-friendly реализации функции

На нормальную перегрузку перейти не получится, ибо это минимально-воспроизводимый пример, в оригинале одна foo, имеющая две перегрузки с разными тегами и весь набор шаблонной магии, включая очень глубокие рекурсии

Ну, мне кажется, что для пользователя это максимально не ожидаемое поведение:
* мы предоставили foo2
* foo1 нигде не должна вызываться
* но почему-то компиляция падает

Но и со стороны библиотеки всё корректно реализовано, а попытка сделать так, чтобы у пользователя всё хорошо работало может привести  тому что, пользователь даже не узнает, что сделал что-то совершенно некорректное, просто foo1 будет лежать мёртвым, невалидным грузом в кодовой базе

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

что касается контраргументов, которые вы привели в конце, то а) библиотеки ценны не корректной реализацией, а хорошими интерфейсами и контрактами, в том числе сообщениями об их нарушении; б) мертвый груз отброшенных шаблонов и тихие ошибки это непременные спутники SFINAE, поэтому я бы не записывал их в недостатки конкретно третьего решения

Хм, спасибо, я понял и мне кажется ваша аргументация убедительной. Полагаю, если больше никто не укажет какие-либо интересные (контр)аргументы, то я выберу именно третий вариант

А нужен ли trail type в bar_impl? Если использовать просто вывод типа через auto оно собирается.

Вообще изначально я думал добавить static_assert, чтобы выдать пользователю вменяемое сообщение об ошибке.