Линус Торвальдс пояснил свою позицию в отношении приёма изменений на Rust

, а тут шаблоны довольно искусственные Чем они «искусственные» и какие бывают «естественные»?

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

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

Шаблоны С++ более выразительны, нет этих дурацких аннотаций derive, ясно прямо из шаблона, чем что параметризовано.

Ха-ха. Так ясно, что приходится городить нечто подобное?

typename boost::disable_if< boost::is_base_of<A, T> >::type function(T const& t);

Выразительность 80-го уровня, ага.

Вопрос, зачем ты до этого докапываешься?

Я не докапываюсь. Я честно признался, что не понимаю что там написано и что к чему относится. Как можно использовать настолько интуитивно непонятные языки?

Я не хочу спорить о том, в чем мало понимаю. В частности, я плохо понимаю, зачем нужен язык с классами и без наследования. А так же не понимаю, зачем в коде раста вечный self и к чему он относится? Ну прям объектная ориентированность как в Питоне, чесслово.

Вот пример попроще — https://doc.rust-lang.ru/stable/rust-by-example/trait.html

Вот объясни мне, если Овца является Животным и создается с целью использования интерфейса Животного, то за каким хреном возможен вызов метода «стрижка»? Интерфейс Животное метода «стрижка» не содержит. Все эти трейты, получается, являются чем-то сбоку прикрученными. То есть, получается, что вместо наследования имеется какая-то неявная параметризация. Шаблонов нет, но на лицо этакая параметризация через шаблон.

И если нам понадобится Волк, то придется писать

impl Animal for Wolf

Ну и что сказать-то типажами хотели?

Ха-ха. Так ясно, что приходится городить нечто подобное?

К счастью, уже не приходится. В последних стандартах как-то с этим кривым SFINAE поборолись. Видать, сами поняли, что нагородили лишней cложности, переболели Александреску головного мозга, походу. Да и возражение это в духе «а у вас негров линчуют».

Вот пример попроще — https://doc.rust-lang.ru/stable/rust-by-example/trait.html

вот на этом примере видна чудовищность рустораста.

перечисляем

1. на основании описания

struct Sheep { naked: bool, name: &'static str }

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

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

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

а если таких вот «классов» в модуле много… то запутаться тут запросто.

– 2. это видимо косорукая форма записи нестатического(в терминах с++) метода.

fn name(&self) -> &'static str;

–

3. странный выбор ключевого слова impl.

impl Sheep

смысл термина имплементация в том, что так обозначается реализация ранее об`явленной декларации нечта. но Sheep это просто структура, и в ней ничто не декларируется, кроме полей. то есть «реализация списка полей» … это звучит просто неграмотно.

по смыслу должно быть не impl, а bindings(типа того) - то есть описание связанных с типом функций.

короче парни тырили у вирта с его обероном, но не читали, что он там написал словами вокруг.

 // Можно переопределить методы по умолчанию, заданные в типаже.
    fn talk(&self) {

если это типа виртуального метода с++, то надо вводить спецификатор навроде override. иначе можно переопределить не тот метод, или вообще никакой не переопределить, просто ошибившись буковкой.

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

Врёт. Я её вот тут взял

Гугл врет. А юзерс-растланг не врет. Окей.

Сайт белого дома байденовской администрации переехал в архив на bidenwhitehouse-archives-gov. Со всеми пресс-релизами.

Кстати, а firefox уже на раст переписали?

Я не докапываюсь. Я честно признался, что не понимаю что там написано и что к чему относится. Как можно использовать настолько интуитивно непонятные языки?

Перефразируя Джона Карлина, проблема не у языка, проблема у тебя. Мне там всё понятно. А если настолько простую конструкцию ты не можешь понять, то причём тут язык? Иди пиши на Питоне.

Все эти трейты, получается, являются чем-то сбоку прикрученными.

Что значит «сбоку прикрученны»? Интерфейс это интерфейс и для типа может быть реализовано несколько несколько интерфейсов. Теоретически вообще можно было бы реализовать несколько реализаций одного и того же интерфейса для одного типа, но создатели Rust посчитали что это уже слишком.

И если ты хочешь стричь животное то должен принимать на вход тип который реализует интерфейсы Животное и Стрижка. Хочешь чтобы твой тип Wolf считался животным - реализуй соответствующий интерфейс, хочешь чтобы его ещё и постричь можно было - реализуй Стрижка. Что тут сложного? Это настолько просто и элементарно.

Ты просто укушен плюсовым ООП, в этом твоя проблема. Если бы ты хотя бы c Жабой поработал, то не задавал бы таких глупых вопросов.

Ты просто укушен плюсовым ООП, в этом твоя проблема. Если бы ты хотя бы c Жабой поработал, то не задавал бы таких глупых вопросов.

В Жабе есть интерфейсы… и есть наследование. И они друг другу не мешают.

Ты просто укушен плюсовым ООП, в этом твоя проблема.

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

И если ты хочешь стричь животное то должен принимать на вход тип который реализует интерфейсы Животное и Стрижка. Хочешь чтобы твой тип Wolf считался животным - реализуй соответствующий интерфейс,

Согласен, только метод «стрижка» интерфейс не предусматривает. Вас это не удивляет?

Ты просто укушен плюсовым ООП, в этом твоя проблема.

Ну уж какой есть, остальные не выжили. Писал бы на Clu, но он умер раньше, чем я программировать научился. Вся остальная «объектная ориентированность» — это пародия. Ну может еще ObjectiveC остался, и тот современные неосиляторы пытаются заменить на Свифт.

Если бы ты хотя бы c Жабой поработал, то не задавал бы таких глупых вопросов.

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

странный выбор ключевого слова impl.

Ничего странного. В Rust гендерно-нейтральное ООП, на гормонах и с отрезанной пипиркой. Т.е. это не классическое наследование вида

class Wolf extends Animal

а реализация интерфейса (которое у них называется наследованием):

impl Animal for Wolf

Тут буквально попытка вырезать гланды через зад так сказать. Не класс Wolf наследуется от родительского Animal и добавляет свои методы и свойства, а реализуется типаж Animal для структуры Wolf, те реализуются все методы «родителя1».

Это очень похоже на классические интерфейсы вида

interface Animal {
...
}

class Wolf implements Animal

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

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

Кстати, gaylord - я все еще жду ответ на два простых вопроса, больше суток прошло.

Шире не значит лучше, потому в Яве то же множественное наследование нафиг выкинули. А расту ООП в стиле плюсов не очень-то и нужно, и легко обходятся без него.

в Яве то же множественное наследование нафиг выкинули

Потому что не догадались что можно решить ромбовидную проблему простым приоритетом порядка следования:

public class Child extends Parent1, Parent2

т.к. Parent2 - последний в списке, то по принципу «кто последний тот и папа» все используемые методы в Child существующие и в Parent1 и в Parent2 берутся как методы из Parent2. Красиво, изящно, все довольны. Со временем, к этому придут, пока же будут грызть множественную реализацию интерфейсов.

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

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

Ну, то есть, девочка-ОЯШ примеряет новый наряд, все думают, что она теперь прекрасная фея, но она остаётся девочкой-ОЯШ. Все ясно, «теперь банановый». Обертки все это, такие обертки и симулякры...

а реализация интерфейса (которое у них называется наследованием):

я не про этот случай, а про запись вида:

struct Sheep { naked: bool, name: &'static str }

...

impl Sheep {
    fn is_naked(&self) -> bool {
        self.naked
    }

    fn shear(&mut self) {
        if self.is_naked() {
            // Тип, реализующий типаж, может использовать другие методы этого же типа.
            println!("{} is already naked...", self.name());
        } else {
            println!("{} gets a haircut!", self.name);
            self.naked = true;
        }
    }
}

тут никакой интерфейс не реализовывается. тут просто описываются байдинги (методы) к структуре Sheep.(насколько я понимаю этот расторуст).

в с++ это было бы описано прям в классе Sheep, или хотя бы обьявлено в нем.

class Sheep : public Animal { 
   bool naked;
   string name; 

public:
   bool is_naked() const { return naked; }
   void shear();
}

и такая декларация класса лучше, чем то, что расторусте. потому что она целостная, и сразу понятно, какие методы у класс Sheep, и какие интерфейсы он реализует.

Шире не значит лучше, потому в Яве то же множественное наследование нафиг выкинули.

в яве множ наследование есть, но только для абстрактных классов, которые они стыдливо назвали интерфейсами. а руст еще стыдливей интерфейсы назвал трейтами.

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

вот это и сделано с с++.

такая декларация класса лучше, чем то, что расторусте. потому что она целостная, и сразу понятно, какие методы у класс Sheep, и какие интерфейсы он реализует.

Такая декларация класса хуже, чем то, что в расторусте. Потому что в большом классе объявления перемешиваются хотя бы за счёт разной видимости, и становится трудно отследить, какие поля вообще есть в классе. Методы видны среди объявлений полей, но не видно, к какому из интерфейсов они относятся. Приватные методы торчат всем на загляденье. Точно ли такая «целостность» лучше?

я не про этот случай, а про запись вида:

Это частный случай того что я описал, просто взгляните на код еще раз перейдя в классическую ООП терминологию (заменив в голове «struct» на «interface»). Т.е. буквально:

interface Ship {
...
}

class Ship implements Ship{
...
}

Потому что в большом классе

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

путиница в с++ с гигантскими классами(которые выглядят странно, при надлежащем проектировании), конечно есть, но если б такой «класс» нарисовать на русте - все было б еще страшней.

Методы видны среди объявлений полей, но не видно, к какому из интерфейсов они относятся

это да. грамматику с++ тут стоило бы дополнить, разрешив указывать какой конкретно интерфейс имеется ввиду, (я такое просто пишу ручками)

это да. грамматику с++ тут стоило бы дополнить, разрешив указывать какой конкретно интерфейс имеется ввиду, (я такое просто пишу ручками)

Так она же уже есть, такая грамматика. При наличии явного наследования от соответствующего абстрактного класса (читай — интерфейса) и так ясно какой конкретно интерфейс имеется ввиду. Рекомендую посмотреть, как реализована автогенерация С++-ных интерфейсных классов в libdbus-c++ или sdbus++.

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

И почему это создатели Явы и Раста стыдливо вводжили понятия? Ты думаешь создатели языков думали об анонимусе с ЛОРа когда вводили соответствующие понятия в свои языки, чтобы он их не пожурил, что у них не такая реализация ООП как он привык в плюсах и поэтому они специально от него спрятались?

Да и вообще, это Страуструпу стоит стыдиться, т.к. у него костыли и подпорки вместо ООП, которое запилили Алан Кэй и Дэн Ингаллс в Smalltalk.

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

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

это как потомок будет нести свойства и отца и матери. почему он должен нести свойства только одного родителя?

и так ясно какой конкретно интерфейс имеется ввиду

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

Как раз С++ строго следит за тем, что бы виртуальные функции наследника имели ту же сигнатуру. Да и слово override придумали. — https://en.cppreference.com/w/cpp/language/override

он то следит. ты не следишь.

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

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

Ну вот напиши override, что бы самого себя проверить. Я сам так налетал на опечатки, они везде бывают.

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

Ну вот напиши override, что бы самого себя проверить.

class X: 
   public iface1,
   public iface2
{
  override void f1(..) {..}
  override void f2(..) {..}
}

вот тут читателю неясно, от какого интерфейса переопределяется метод. надо смотреть в их декларации, а это лень.

а вот если б была запись:

class X: 
   public iface1,
   public iface2
{
  override void iface1::f1(..) {..}
  override void iface2::f2(..) {..}
}

тут все понятней некуда.

Там хуже другое. Вот это компилится и работает:

#include <iostream>

class P1 {
public:
    virtual void f() = 0;
};


class P2 {
public:
    virtual void f() = 0;
};

class C: public P1, public P2 {
public:
    virtual void f() override {
        std::cout << "Hello, world!" << '\n';
    }
};

int main () {
    C c;
    c.f();
}

ну вот ты сам ответил на вопрос - зачем

Да, как бы, мы недостатки С++ не обсуждаем, их есть. Я-то, честно говоря, надеялся с такими декларациями получить конфликт имен, и не получил его. Вот сам удивился. Кстати, в этом случае предполагаемый явный спецификатор интерфейса не поможет. Сигнатуры-то функций одинаковы в обоих интерфейсах. И заоверрайдить обе не получится.

Кстати, в этом случае предполагаемый явный спецификатор интерфейса не поможет.

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

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

В данном примере как ты заоверрайдишь две одинаковые функции по разному?

Ну как бы да, именно так.

#include <iostream>

class P1 {
public:
    virtual void f() {
        std::cout << "Hello, P1\n";
    };
    virtual ~P1() {}

};

class P2 {
public:
    virtual void f() {
        std::cout << "Hello, P2\n";
    };
    virtual ~P2() {}
};

class C: public P1, public P2 {
public:
    virtual void f() override {
        std::cout << "Hello, world!\n";
    }
    virtual ~C() {}
};

int main () {
    P1 *p1 = new C();
    P2 *p2 = new C();
    p1->f();
    p2->f();
    delete p1;
    delete p2;
}

gleb@develop-3:~/tmp$ clang++ -o test test.cxx 
gleb@develop-3:~/tmp$ ./test 
Hello, world!
Hello, world!

почему ненужным-то

По статистике.

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

Таки нужно. См. sdbus++. Там без этого никак.

По статистике.

нет такой статистики. вопрос - есть какое-то теоретическое объяснение, почему нельзя наследовать два класса? чему это мешает?

Много сложностей и, как правило, не нужно. Подход с интерфейсами намного практичнее.

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

Как хорошо что мы живём в 21 веке и полно таких штук как IDE.

Любой подход имеет достоинства и недостатки. Плюсовый (жабий, шарповый) склонен прятать данные между кучей объявлений (а в случае жабы и шарпа и реализация) функций, а в расте наоборот, все данные физически присутствующие в структуре, изначально видны, а также, благодаря tagged union, в самой структуре структуры отражены взаимоотношения между полями. Зато в плюсы и вы жаба позволяет увидеть интерфейс класса в объявлении, а в расте это где-то спрятано. Правда тут же стоит звёздочка и внизу мелким шрифтом добавлено, что это актуально только если отказаться от наследования реализаций, что есть методы расширения и вообще, по мнению Страуструпа, функция foo(Bar&a, Bar&b) так же является частью интерфейса класса Bar, но при этом она может находиться где угодно.

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

struct Foo {
...
}

impl Foo {
...
}

impl Bar for Foo {
...
}

И всё более-менее читаемо. А если не захочет, то раскидает повсюду, но и в классических ООП языках будет всё ровно то же, размазанная по дереву наследования реализация, отсутствие явных интерфейсных предков и т.п.

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

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

правка: превращает код во write only помойку

А вот и Крис под звуки песни гр. Ленинград «Дорожная» самовыпилился из мейнтейнеров. Не велика потеря :)

И это ужасно.

И всё более-менее читаемо.

Представляешь, так можно на «овердохуа» языков сделать и будет читабельно.

Потеря как раз таки велика. Тут с сопровождением одноязыкового ядра - тормоза, а сопровождать месиво из языков - будет та ещё жопа.

Потеря как раз таки велика.

Это вообще не потеря - ни в одной подсистеме он не был единственным мейнтейнером.

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

Тормоза у тебя в голове. В реальности ни одно другое ядро и близко не может похвастаться темпами развития линукса.

сопровождать месиво из языков - будет та ещё жопа

Справятся, хотя искренне надеюсь что со временем перейдут исключительно на Rust для всего нового кода.

Ну а там и трансформеры на основе LLM подтянутся до приличного уровня и можно будет старьё перегнать в современную кодовую базу.

Как хорошо что мы живём в 21 веке и полно таких штук как IDE.

то есть и брейнфак отличный язык, ему просто нужно хорошее ide?

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

И всё более-менее читаемо

да фигово это читаемо… кстати, что будет если имплементировать два интерфейса в которых есть функции с одной сигнатурой? например print().

А вот и Крис под звуки песни гр. Ленинград «Дорожная» самовыпилился из мейнтейнеров. Не велика потеря :)

https://www.opennet.ru/opennews/art.shtml?num=62797

Кристоф Хелвиг (Christoph Hellwig) ушёл с позиции мэйнтейнера подсистем dma-mapping и configfs. Уход ограничился отправкой заявки на удаление из списка мэйнтейнеров и сообщением о передаче управления оставшимся сопровождающим. В подсистеме dma-mapping сопровождение продолжит Марек Шипровски (Marek Szyprowski) из Samsung, а в configfs - Джоэл Беккер (Joel Becker) из Oracle.

Кристоф Хелвиг пока остаётся в числе мэйнтейнеров подсистем NVM Express, vmalloc и FreeVXFS. В прошлом Кристоф входил в управляющий технический комитет организации Linux Foundation и участвовал в разработке таких подсистем, как XFS, KVM, Trace events, SCSI и Slab Allocator, а также занимался сопровождением архитектуры PowerPC в ядре Linux. Кроме того, Кристоф выступал истцом в судебном разбирательстве с VMware, связанном с нарушением лицензии GPL.

Прекращение сопровождения подсистем dma-mapping и configfs обусловлено заявлением Линуса Торвальдса о намерении включать в ядро обвязки на языке Rust независимо от согласия мэйнтейнеров подсистем, для которых созданы данные обвязки. В январе Кристоф принципиально отказался принимать в ядро Rust-обвязку над функциями для работы с DMA, что привело к конфликту, в результате которого ядро покинули мэйнтейнеры подсистем Nouveau и ARM/Apple. 24 февраля разработчики проекта Rust for Linux предложили патч со слоем абстракции для ФС configfs, сопровождением которой занимался Кристоф Хелвиг. Кристоф не принял участие в обсуждении новой Rust-обвязки к своей подсистеме, а через несколько дней удалил себя из списка мэйнтейнеров dma-mapping и configfs.

Кристоф Хелвиг считает недопустимым использование нескольких языков программирования в таких сложных проектах как ядро Linux. По мнению Кристофа, смешанные кодовые базы усложняют работу мэйнтейнеров, так как ставят мэйнтейнеров в зависимость от кода на другом языке. В частности, при наличии обвязок на Rust разработчики подсистем, написанных на Си, должны учитывать влияние их изменений на продолжение работоспособности обвязок. Любое изменение структур данных или внутренних функций на Си может привести к необходимости изменения кода обвязок, поэтому влияющие на обвязки изменения в Си коде нужно отслеживать и синхронизировать с кодом на Rust.

В процессе разработки ядра уже были факты отклонения pull-запроса с изменениями в подсистеме управления памятью, так как данное изменение приводило к сбою при попытке сборки ядра с включением поддержки Rust. Сбой возник из-за рассинхронизации с кодом для генерации Rust-обвязок (bindgen) и привёл к тому, что сопровождающие подсистему управления памятью при продвижении изменения, полностью корректного с точки зрения кода на Си и ядра в целом, оказались зависимы от опционального стороннего кода в ядре, за который отвечают другие люди.

Линус Торвальдс считает, что Кристоф Хелвиг не имеет полномочий блокировать приём в ядро Rust-обвязок для подсистемы DMA, так как код данных обвязок не затрагивает код подсистемы DMA Mapping и реализован в отдельном подкаталоге, сопровождением которого занимается отдельный мэйнтейнер. Линус сравнил действия Кристофа с попыткой контролировать область использования подсистемы DMA, при том, что мэйнтейнеры отвечают лишь за код своей подсистемы, но не за то, как и кем используется результат работы этого кода. Например, изменение в коде базовых подсистем может привести к проблемам с работой какого-то драйвера, но это не повод вмешиваться в приём новых драйверов.

Кристоф Хелвиг считает недопустимым использование нескольких языков программирования в таких сложных проектах как ядро Linux.

Конечно! Жаль, что адекватные уходят.
Линус дождётся, что они консолидируются и сделают pure-c-linux.

они консолидируются и сделают pure-c-linux

LOL! Ты в каком болоте последние 25 лет сидел?! Посмотри кто именно контрибьютит подавляющее большинство кода в ядро.

Максимум что может дать консолидация недовольных это небольшая комнатка на задворках FOSDEM. И это даже без учёта того что hate driven development традиционно ведёт в никуда.

Держи 🤡. Но ты совсем несмешной, тренируйся!

правка: превращает код во write only помойку

Когда плюсовики с наследованием реализации начинают свистеть что-то про write-only помойку, это весело.

Нет, не превращает. Растишка позволяет реализовать для чужого типа свой типаж или для своего типа чужой типаж. Т.е. либо ты понимаешь что int применим с некоей целью в рамках твоего кода и ты описываешь это, либо что твоя структурка применима в рамках чужого. Просто взять и добавить произвольный типаж к произвольному типу нельзя.

И? Ну да, будет.

Можно в плюсах, например, #define TRUE FALSE написать, да ещё и табуляцией спрятать. Мой поинт в том, что проблема высосана из пальца и вообще чистый синдром утёнка