На расте оставлю только рендеринг

в итоге все перепишешь на питон

Размечтался

Мне совсем немного осталось на расте допилить

Потом сделаю весь парсер на расте

И будет секси

а зачем у тебя питонская часть?

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

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

там забавный момент в том, что если указывать зависимости типа rand = { path = "~/.cargo/path-ro-rand" } , то это всё равно нифига не работает, потому что зависимости зависимостей хотят в crates.io. Прописывать также путями не помогает

Есть patch.crates-io

Читай доку по манифесту

Читай доку по манифесту

круто, спасибо, то, что нужно. В мои времена таких штук не было)

как у тебя, кстати, количество rust кода на работе растёт?

а почему bool определен как примитив а не как enum Bool { True, False }?

а почему bool определен как примитив а не как enum Bool { True, False }?

а где бул так определен?

как енумерация?

да

довольно глупый вопрос

в хаскеле например

потому что раст не хаскель, например

специфика немного другая у него

а почему bool определен как примитив а не как enum Bool { True, False }?

Байтодрочинг?

потому что раст не хаскель, например

что это за аргумент?

стопроцентный

и не поспоришь даже

я думаю что енумерация не должна работать медленнее чем хардкодинг определенного типа

я еще с десяток таких могу привести

на самом деле да, потому что, видимо, быстрее так работает, возможно, потом они это переделают

можешь побенчить

на самом деле да, потому что, видимо, быстрее так работает, возможно, потом они это переделают

не должно быть причины по которой собственный enum работал бы медленнее тогда

я думаю что енумерация не должна работать медленнее чем хардкодинг определенного типа

Ну если у тебя тупые C-like enum'ы, то это просто подмножество unsigned'а, но когда у тебя enum'ы это нормальные sum type'ы, то это уже не так

ну в языке уже есть разделение между C-like и DU

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

а в чем профит-то?

pattern matching

он и так работает

не, мне просто кажется странным и ненужным хардкодинг bool

MIR код почти не отличается при использовании встроенного и енума

🤔🤔🤔🤔

а зачем у тебя питонская часть?

ast парсер wiki кода есть только на питоне

на расте нету

потом сам напишу

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

а всякое говно подчищаю и правлю по ходу дела

не, мне просто кажется странным и ненужным хардкодинг bool

Пришлось бы добавлять перегрузку логических операторов

if'ы и while'ы стали бы более многословными

а сейчас по-другому?

if'ы и while'ы стали бы более многословными

каким образом?

каким образом?

Если бы bool был таким же enum, как и пользовательские энумы - пришлось бы сравнивать условия с True и False.

зачем?

Можно было бы конечно сделать bool магическим енумом

Но тогда какая разница?

зачем?

А зачем enum bool?

чтобы не хардкодить ничего

ну в этом и вопрос, что магию все равно добавлять

так что профита 0

те же енумы все равно в release так же представляются

сейчас

чтобы не хардкодить ничего

Так если if ("захардкоженный" оператор языка) будет понимать enum bool, то этот enum bool тоже надо будет захардкодить

ну, мне кажется, что проверять что именно Bool приходит как аргумент в if во время компиляции это намного лучше чем сейчас в любом случае

на самом деле можно даже без этого но могут появлятся неявные ошибки

чем лучше-то объясни

мне кажется использование енумерации в std вместо примитива упростит компилятор и логичнее для пользователя

сейчас true/false это вообще зарезервированые кейворды

(//_\\)

Язык он может упростить, сократив число сущностей. Но компилятор от этого вряд ли станет проще :) Да и в любом случае, у bool'а всегда будет более значимый статус в языке, чем у энума с двумя значениями.

Так что, ничто, собственно, не упростится

ну как минимум парсер

упростит

в остальном я очень плохо шарю

сейчас true/false это вообще зарезервированые кейворды

Ну и правильно

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

сейчас true/false это вообще зарезервированые кейворды

Зато в го они не зарезервированы! *trollface*

Зато в го они не зарезервированы! *trollface*

Зато в c++ можно переопределить скорее

потом сам напишу

а, ок, заливай на крейтсы когда эцсамое

я тебе уже советовал oak?

не, мне просто кажется странным и ненужным хардкодинг bool

Какая разница, как определили bool?

Представь себе, что он как енум определён

тогда он противоречит компилятору

Хотя, я с тобой согласен