Но для этого и существуют два основных типа строк. Это String и &str. &str можно получить из String или из другого &str, и это указатель+длина в чистом виде
Поэтому anyhow и thiserror так мне никогда и не пригодились. В простейших случаях проще и нагляднее вручную все реализовать. В сложных ситуациях эти крейты и так бесполезны.
Хотя конечно при ручной реализации надо ошибки выносить в отдельный файл, п то быстро запутаться можно
Ну строго говоря типы учить как то особо не надо. Просто используешь их и все.
Например в python есть классы, и их надо как то объявить, так и здесь тоже самое.
Ну есть у тебя функция и она принимает миллиметры. Просто создаешь тип миллиметр и прописываешь что он является входным аргументом. И тебе понятно, что ожидает эта функция и пользователям понятно. И через год тебе тоже будет понятно, а не придётся вспоминать смотря на вызовы функции.
Можно пойти дальше. Ты объявляешь что функция принимает что угодно, если она реализует вон тот интерфейс (грубо говоря у нее есть какая-то определённая функция, которая возвращает определённое значение). Это уже дженерики.
В чем же проблема? Ведь явно прописаны все ИНТЕРФЕЙСЫ типов. Прописывание конкретного типа ничего не изменит. Пользователь и так точно знает что может делать тот или иной входной аргумент.
Несовместимые типы и аргументы, также как их неправильное использование сразу даст ошибку компиляции, ну или в случае с Rust, начнет жаловаться rust-analyzer. Искать ошибку самому нет необходимости.
Ну так IDE в помощь, хотя это конечно не дело объявлять вектор сильно выше использования, за такое надо бить по рукам.
Правда rust-analyzer иногда конечно тупит на сильно сложных выводах, с associated types, GAT и т.д. Особенно когда идет цепочка GAT ?
И автоматический вывод типов на уровне функции очень удобен с поддержкой IDE. Ведь случаи описанные вами крайне редки. Функции обычно стараются делать маленькими, либо разбивать на блоки. Ну а входные и выходные данные функции должны быть прописаны точно
Да нет, я думаю вполне нормальный код rust. Трейты для этого и существуют, чтобы работать с обобщенными типами.
Но для этого и существуют два основных типа строк. Это String и &str. &str можно получить из String или из другого &str, и это указатель+длина в чистом виде
Да, это действительно проблема.
Поэтому anyhow и thiserror так мне никогда и не пригодились. В простейших случаях проще и нагляднее вручную все реализовать. В сложных ситуациях эти крейты и так бесполезны.
Хотя конечно при ручной реализации надо ошибки выносить в отдельный файл, п то быстро запутаться можно
Ну строго говоря типы учить как то особо не надо. Просто используешь их и все.
Например в python есть классы, и их надо как то объявить, так и здесь тоже самое.
Ну есть у тебя функция и она принимает миллиметры. Просто создаешь тип миллиметр и прописываешь что он является входным аргументом. И тебе понятно, что ожидает эта функция и пользователям понятно. И через год тебе тоже будет понятно, а не придётся вспоминать смотря на вызовы функции.
Можно пойти дальше. Ты объявляешь что функция принимает что угодно, если она реализует вон тот интерфейс (грубо говоря у нее есть какая-то определённая функция, которая возвращает определённое значение). Это уже дженерики.
В чем же проблема? Ведь явно прописаны все ИНТЕРФЕЙСЫ типов. Прописывание конкретного типа ничего не изменит. Пользователь и так точно знает что может делать тот или иной входной аргумент.
Несовместимые типы и аргументы, также как их неправильное использование сразу даст ошибку компиляции, ну или в случае с Rust, начнет жаловаться rust-analyzer. Искать ошибку самому нет необходимости.
Ну так IDE в помощь, хотя это конечно не дело объявлять вектор сильно выше использования, за такое надо бить по рукам.
Правда rust-analyzer иногда конечно тупит на сильно сложных выводах, с associated types, GAT и т.д. Особенно когда идет цепочка GAT ?
И автоматический вывод типов на уровне функции очень удобен с поддержкой IDE. Ведь случаи описанные вами крайне редки. Функции обычно стараются делать маленькими, либо разбивать на блоки. Ну а входные и выходные данные функции должны быть прописаны точно
И может быть хранить в структуре также сам аллокатор? Ведь очень часто это просто ZST, и доп размера она иметь не будет
Работает только если использовать Global как аллокатор?.
Прикольная структура, но не знаю, нужно ли все это? ? Есть хоть какие нибудь бенчмарки?
Попробуйте использовать
try_fold, try_for_each, очень удобно))Когда как)) Заметил за собой что много использую
try_fold, try_for_each. Очень полезные и компактные адаптеры, вместо цикла for.Правда нужно организовать код так, чтобы запихать в
try_fold, try_for_eachтолько односложные замыкания или просто имена функцийНе, кажется не умеет. Во всяком случае это не гарантированно компилятором
Супер, а я и не знал)) Спасибо ?
Ну в целом человеческое развитие движется вперёд. Возможно это вас утешит
Ну или больше пытаться ?. Не уверен что можно что-то получить стоящее, запуская миссию раз в десятилетие
Причем во всем. И в курсе доллара тоже ?
Не думаю что ещё что-то будет. Денег нет, но отрасль кажется держится. Пока...
Поправка: с космическим флагом ?
Ну так там все постоянно смывается, чистится, да и бактерии там наши родные. Те что из кишечника ?.
Российские мощности не справляются с производством необходимого количества обычных чипов для карт, а вы смартфоны еще хотите.
Это надо производство расширять, да кто же продаст производственную линию. Даже на те же 60+ нм.
Со временем привыкаешь)) Я вот втянулся.
Он не сложный, просто немного громоздкий что ли? ?