> если проблема не только null?То тогда это другая проблема.
> Не могло бы это выглядеть как-то менее наркомански?
Субъективно - вопрос для опшинал параметров много где используется - в Kotlin и Swift точно. Это уже нормально для для тех кто с ним знаком))
Да и логика в это есть:
fn(a: String) - тут вам пришла строка, работайте спокойно
fn(b: String?) - тут вам пришла строка, но это не точно, поэтому проверьте что там
Так что просто непривычно.
> Это что, везде будет вот эта чисто техническая дрянь на полэкрана?
Скорее нет, чем да. Во-первых оно занимает всего один символ (это если про ?, а если про цепочку вызовов, то никто не мешает их написать каждый одной строкой).
Вы просто не сможете передать в fn(a: String) параметр String? - компилятор не пропустит.
Т.е. есть туда может придти null - то на каком-то этапе вам придется проверить 1 (один!) раз, а дальше работать как обычно - или вы проверяете внутри своей функции если допускаете такое и возвращаете ошибку, или обязываете вызывающую сторону гарантировать валидность входного параметра.
> И профит от этого наступает... например, в чем?
А профит в том что проверка в compile time.
> Они видите ли ни в раз не позиционируются как системные яп...
И это не повод не взять из них хорошую идею)))
> Все меню в итоге являет собой одну большую *константу*
Ну что ж вы сразу не актцентировали на этом внимание)
Вот пример полностью precomputed в compile time - как локальной, так и глобальной: https://play.rust-lang.org/?version=nightly&mode=debug&editi...
> А оно не может в более generic проверки?
Конкретно эта штука - нет. Она решает одну конкретную задачу.
Но есть другие механизмы. Напр. https://crates.io/crates/static_assertions позволяет проверять разные вещи для const объектов в compile time. Возможно это можно сделать макросом самому, но я вряд ли смогу.
Вот что в данный момент раст может делать в compile time - https://doc.rust-lang.org/reference/const_eval.html
Насколько я знаю "Const generics" (https://github.com/rust-lang/rust/issues/44580) еще не в stable и там есть работа, но оно добавит еще возможностей.
С ним можно будет сделать то что вы пишете на уровне языка, а не макросов.
https://github.com/rust-lang/rfcs/issues/1621 - вы просто объявите свой тип и зададите его лимиты от 1 до 100. Но пока насколько я вижу оно еще не готово.
Плюс - ваш пример по фирмварю гироскутера это уже эмбедед, а не системщина. Тут можно начать спорить что такое системщина, а что нет, но предложу чтобы в этом вопросе каждый остался при своем мнении.
> А вон пример специфичной вещи системного программирования. А покажите как это на русте?
Если это было про меню, то вроде показал, если про лимиты для параметров - то сорян, я не настолько крут. Но варианты решения есть выше.
> Но они ориентировались все же на full blown апликухи в основном, а про аналог "freestanding" из C99 кажется не очень задумывались.
Да, наверное они действительно ориентировались на универсальный язык. Поэтому там много высокоуровневых вещей вроде элементов функционального программирования.
Но, в раст есть "режим" no_std, кмк это аналог freestanding.
Если писать в этом режиме то оно вполне работает на микроконтроллерах. Вот тут можно почитать книжку по rust-embedded https://docs.rust-embedded.org/discovery/index.html. А тут список того что поддерживается в том или ином виде https://github.com/rust-embedded/awesome-embedded-rust.
PS: я не пытаюсь вас убедить бросить си и начать писать на расте. Скорее в том что добавление возможности писать драйверы на нем не сделает ядру хуже.
