Было бы логичнее заставить полностью описывать концепт чтоб он покрывал всё тело

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

Почему же обманул? Ты описал требования к типу. Если тип им удовлетворяет - он им удовлетворяет. В С++ это больше нужно для ограничения полиморфизма шаблонов. На этом не построен тайпчекинг, как в тех же генериках

Ну ты описал требования к типу, но потом вызвал у этого типа метод которого там не было. Получается теперь твои требования это не достаточное условие для вызова функции

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

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

В расте в дженериках на уровне типов используется динамический полиморфизм. Но компилятор при генерации кода знает все типы и поэтому не использует динамический полиморфизм в рантайме. Я правильно понял?

Не, это уже идеология которая была накручена поверх. В реальности в динамическом полиморфизме ты НЕ МОЖЕШЬ использовать то, что не описано в таблицы. А далее уже это обросло всякими ахренительными историями про "условия", "достаточно" и прочее. Зачем всё это?

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

И тут концепт никак не поможет, если ты не все требования туда запишешь

Ну по-сути да. Только это не особенность раста - это таково свойство любых генериков. Генерики это попытка описать полиморфный код мономорфным. Там типы никак получить нельзя. Нужна монорфизация. Да, в расте оно происходит в бекенде, когда mir транслируется в llvm-ir

Наоборот, ошибки выводимые подобной системой наиболее непонятны и запутаны. Мы получаем ошибку не там, где должны. При этом концепты этому никак особо не помогают. Ошибка там генерируется такая же, просто немного места поменяны.

Проблема в ошибках в С++ не в том, что они ошибки. А в том, что многие вещи достигаются путём всяких хаков, условно. Вот есть у тебя enable_if, который там что-то чекает и ошибка появится у тебя где-то непонятно где

и вот у тебя теперь есть requires, который отвалится не в кишках enable_if и прочих костыльных трейтах/сфинае-хаках для доставания свойств типов.

сделать красивые ошибки можно и сейчас - тем же статик-ассертом, но он пробивает сфинае.

в концептах они будут куда более страшные. Разница в том, что ранее ты доставал условный begin хаком, который вывалил бы тебе свои кишки. Сейчас ты пишешь requires { begin(); } - который покажет тебе тот же самый трейс, что и обычная ошибка формирования, которая бы произошла в теле

сейчас эти ошибки группируются в requires container_like_concept<T>, например, и ты видишь, что этот концепт провалился, потому что внутри него провалился другой концепт и т.д.

только немного подход поменялся. В обычной ошибке тебе будет трейсить до ошибки и покажет ошибку. Это просто деталь реализации - можно сделать и иначе. А в requires тебе просто сначал сообщат "не смогла", а уже после дадут трейс и покажут почему

Это просто подход, как я писал выше. У тебя есть условный вызов функции - он известен. Далее этот вызов триггерит инстанцирование, который где-то отваливается на уровне тайпчека. Вот ты можешь показать как ошибку тот вызов/шаблон, который он пытался инстанцировать. Либо можешь показать место, где отвалился сам тайпчекинг.

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

ну и самое важное, ошибку концепта ты вообще никогда не должен мочь видеть. Если же ты её видишь - у тебя один шаблон и тебе хватит static_assert, который сгенерирует ошибки те, которые хочешь ты. Самые красивые

улучшения там - это когда читаешь трейс компилятора с причинами отброса кандидатов