Ребята, давайте кончайте философствование. Даже трудно уже вникнуть в суть вашего спора.

👋

Ну зашла речь о сигнатурах и была использована отсылка к "святой сигнатуре", т.е. миру, где сигнатура определяет всё. В С++ это не так. На это последовал ответ "святая сигнатура - это круто. Нужно, чтобы все последовали и всё изменится". И уже на это последовал мой ответ о том, что завязка на сигнатуре - это лишь следствие ограниченности возможностей. А комплексный анализ куда более мощный

template <typename T> auto foo() {}
template <typename T> decltype(auto) foo() {}

template <typename T> ConvertibleToBool auto foo() {}

А почему так вышло? Семантически auto и decltype(auto) вроде эквивалентны.

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

С тем же noexcept уже так не получилось. И теперь мучаемся и пишем то,  что могло бы быть выведено. И написание нормальных noexcept-правил это то ещё приключение. А почему? А потому что сигнатура.

А const/не const - в С влияет на сигнатуру?

В си нет перегрузки, поэтому там сигнатура на самом деле не так важна. Ну и не так давно там и const'а не было.

манглинга нет, да

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

Это так и есть, да

Ну вот получается, что аналогия с интерфейсами слабая

Интерфейсы именно ограничивают использование набором методов

Отвечу подробней. В сишке связывание вызова/тела происходит через таблицу символов. А сам символ - это его имя. Оно не зависит от сигнатуры. В С++ имя символа формуруется из всей сигнатуры, опять для того, чтобы работало сишное "связывание".

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

Нет, так и работает ограничение. Просто все интерфейсы реализованы поверх vtable. Для того они и были созданы. Тип же оригинальный затирается и весь доступ к типу производится только через интерфейс

интерфейсу же будут удовлетворять классы/иные сущности, в которых методов больше, чем определено в нём(интерфейсе)? Это правильно. Нельзя обратиться, но это особенность динамического полиморфизма.  Это не свойство ограничения.

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

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

Нет. В дженериках (шаблонах по нашему) нет динамического полиморфизма.

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

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