Кстати, я заметил что кейворды abstract, virtual, override - зарезервированы,

значит есть надежда?🌚

по-моему это ненужный сахар, пусть там в резерве и лежат, не надо из раста монстра делать, как с++

Это печально. Не обязательно ведь монстра нужно делать, какое-нибудь одиночное наследование и все🌚🌚

https://t.me/rust_beginners_ru/179563 вот здесь у человека были проблемы с наследованием, участники группы предложили выход из ситуации. в принципе все ооп-шные проблемы можно решить в расте штатными средствами. имхо излишний инструментарий не нужен в компилируемых языках - любая фича так или иначе сказывается головной болью для разработчиков компилятора. зачем это нужно?

плюсовое наследование, которое смешивает делегацию и динамический полиморфизм, можно не ждать,но вот про статическую делегацию разговоры давно идут и возможно таки что-то в итоге из них родится https://github.com/rust-lang/rfcs/issues/349 но так-то да, неплохих альтернатив для большинства ситуаций язык уже предоставляет

Как с goto в Java, ага

а что с кивордом typeof?

да хотя бы сделайте наследование реализации методов в трейте

мелькал в нескольких rfc и обсуждениях, из которых ничего пока не вышло. если надо тупо имя типа получить, то в стд есть https://doc.rust-lang.org/std/any/fn.type_name.html

2014 год... Ну-с, вряд ли))

ну вообще, да, скорее всего вне темплейтов он не нужен, а темплейтов в расте нет

не факт, ага. но, с другой стороны, запросы HKT тоже с 13 года висят и с GAT'ами движуха таки разогналась в последние годы

Нет смысла добавлять в раст наследование- все решается композицией

У наследования и композиции свои удобные юзкейсы

Наследование – это крайнее средство. Как правило всегда есть способ сделать лучше. Но иногда надо. Но ради этого в язык добавлять не стоит

И почему это крайнее средство?

Потому что практика показывает, что оно плохо выражает идеи. Потому что другие средства позволяют сделать архитектуру лучше и код короче. Потому что вообще объекты – это замыкания для бедных (тут конечно в Раст много специфики, но всё равно это стоит помнить)

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

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

Ну так а зачем иначе строить архитектуру. Вот есть у меня допустим потребность в написании тестов. И для этого мне нужно в каждый отдельный тест прокидывать некоторый контекст. Почему бы не сделать это с помощью наследования, а выбирать какую-то другую архитектуру? Мне хочется узнать на примере, как это работает, абстрактно это ни о чем не говорит, кроме «делай хорошо и хорошо будет».

Это вопрос из серии "зачем делать отступы в коде". У программистов, постигших классическое ООП (то есть у примерно всех), есть когнитивное искажение: бездумное следование определенной схеме. Чтобы его преодолеть, чтобы не застрять на уровне развития "умею пользоваться ООП", а дойти до уровня "умею не пользоваться ООП", нужно постараться. Вот например наблюдение из практики. При наследовании зачастую код специфического назначения оказывается в базовом классе, хотя он там как собаке пятая нога. Грубо говоря, если вам надо добавить животному поведение при встрече с человеком, нужно запихнуть в базовый класс абстрактный метод. Чувствуете запахло недекомпозированностью и сложностью "m x n" вместо "m + n"?

Первый абзац комментировать не буду, скажу только, что уверенность в своей правоте это худший способ доказать что-то. Особенно, когда кроме него ничего нет. Так вы не останавливайтесь в этом примере на моменте со сложностью. Вы расскажите, как эта сложность решается. Заодно можете рассказать, почему "Грубо говоря, если вам надо добавить животному поведение при встрече с человеком, нужно запихнуть в базовый класс абстрактный метод." это решение в духе наследования, а не просто плохое.

Сложность решается с помощью алгебраических типов данных. Если в данном случае нет противопоказаний к использованию ADT. А если есть, то решается иначе. Индивидуально в каждом случае. Я упоминал ECS. Или надо аккуратно воткнуть в нужное место Any. Суть в том, что решение индивидуально

То есть, мы пришли обратно к тому, что все индивидуально и нет обоснования для фразы "Практика показывает, что оно плохо выражает идеи". Потому что на практике просто оказывается, что инструмент был применен неправильно или его не нужно было применять в конкретном случае. И я напомню, что изначальное я об этом и сказал - у каждого инструмента(будь то наследование или композиция) свои юзкейсы.

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

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

Возможно. Но я прежде хотел бы увидеть в Rust impl Trait through Field и посмотреть на количество оставшегося бойлерплейта

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

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

Да просто у ООП реклама лучше, так еще и рекламируют, как универсальное решение, к сожалению.