если туда не лезть, то жить можно

хм. Тогда надо говорить не "полиморфизм подтипов", а именно "полиморфизм типов"?

И рассматривая вещи так, то добавляя любой узел (любой тип) в какой-то класс (присасываешся классом к произвольному узлу), ты не влияешь на “наследников”. Но если ты меняешь сам тайпкласс - это отразится на иерархии и прокинется вниз.

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

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

ну тогда не вижу принципиальной разницы

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

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

в крестах ты берёшь новый класс и наследуешься от исходного класса + от нового класса. Получился тоже самое примерно с точки зрения получения результата. Или нет?

в расте можно в трейте реализовывать другой трейт (типа иерархии)?

A:B, но это не оч так работает

А ещё можно impl Trait for Trait

Это не то же самое, вчера обсуждалось ещё, если не ошибаюсь

Это скорее = должны быть реализованы оба трейта

чтоб сравнить мощь разных языков. Вот я офигеваю, как круто в c++ сделано. Да, можно выстрелить в ногу, но если ты мастер, то такииие вещи можно творить

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

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

1. Трейты не являются ни классами, ни интерфейсами. Они позволяют, тем не менее, как и интерфейсы, задавать контракты вызовов функций на типе.
2. Трейт баунды - не наследование интерфейсов. Они широко поощряют статическую диспетчеризацию, предоставляя мощный инструмент накладывания ограничений на известные типы.
3. Динамическая диспетчеризация поддерживается (в форме Box<dyn Trait>), однако и тут есть различие с c++. Для каждого трейта существует своя виртуальная таблица вызовов, указатель которой добавляется к dyn, что не позволяет напрямую кастовать трейты между друг другом даже при наличии баундов. Кроме того, они должны быть object safe, чтобы поддерживать дин диспатч.

Ок, спасибо за информацию
Я нашел несостыковку в своей логике
https://users.rust-lang.org/t/extending-traits/

pub trait A {}
pub trait B: A {}
However, this does not mean that if a type extends B it will automatically extends A; trait inheritance is just a way to specify requirements, that is, trait B: A means that we can know that if some type T implements B, it also necessarily implements A.

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

Почему трейты совершенно не похожи на классы - да на самом деле очень просто и понятно, классы наследуют поведение и структуру данных, и для них релевантна diamond problem

Насколько знаю, очень много хорошего в c++ делается через шаблоны, а шаблоны порой пугают

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