> То тогда это другая проблема.Нельзя более общо сделать было? Это ж частный случай проверок параметров.
> Субъективно - вопрос для опшинал параметров много где используется - в Kotlin
> и Swift точно. Это уже нормально для для тех кто с ним знаком))
Ну знак вопроса хрен с ним. А всю такую штуку на полэкрана реально оформить макро с говорящим названием вместо печати таких прелестей?
> fn(b: String?) - тут вам пришла строка, но это не точно, поэтому проверьте что там
С одной стороны идея интересная. С другой это звучит как поле для грабель и могу себе представить что в safety critical если оно дотуда доберется это позапретят нафиг.
> Скорее нет, чем да. Во-первых оно занимает всего один символ (это если
> про ?, а если про цепочку вызовов, то никто не мешает их написать каждый одной строкой).
А оформить всю подобную цепочку и т.п. каким-нибудь коротким макро реально?
> Вы просто не сможете передать в fn(a: String) параметр String? - компилятор не пропустит.
Вот мне и стало интересно насколько далеко раст умеет заходить с compile-time проверками. Просто глупо если компилер внутрях умеет в range-check но наружу это не вывешено особо.
> Т.е. есть туда может придти null - то на каком-то этапе вам
> придется проверить 1 (один!) раз, а дальше работать как обычно -
Я и так все входные параметры функции 1 раз проверяю, в начале. Даже на си. Это тупо стандартное требование всех safety-critical и т.п. гайдов. А фича то в чем?
> или вы проверяете внутри своей функции если допускаете такое и возвращаете
> ошибку, или обязываете вызывающую сторону гарантировать валидность входного параметра.
Мне был интересен случай когда функция жрет заведомо ограниченный range параметров и было бы очень круто если бы компилер мог проверить что они всегда именно такие. Да, это подразомевает некие ограничения (вычисляемые в runtime значения поддаются этому только частично).
> А профит в том что проверка в compile time.
Это то хорошо, мне такие вещи нравятся.
>> Они видите ли ни в раз не позиционируются как системные яп...
> И это не повод не взять из них хорошую идею)))
То что хорошо для мягкотелых хипстеров - порой острый нож в системщине. Вон питонятина постоянно валится с рантайм еррором. А если так фирмварь гироскутера будет, хипстер станет с синим лицом, беззубый, и гироскутер продаст от греха.
>> Все меню в итоге являет собой одну большую *константу*
> Ну что ж вы сразу не актцентировали на этом внимание)
Собссно прелесть макро в сях в том что оно generates no code, а const не даст это менять, учитывая что это массив struct разного размера это предотвращает много стремных ситуаций. Compile-time генереж таким манером заполнит как надо а в рантайм его никто не трогает. Места для лажи мало.
> Вот пример полностью precomputed в compile time - как локальной, так и
> глобальной: https://play.rust-lang.org/
Что-то не грузится. Может ему tor не нравится? Или кто там его знает. На что-нибудь менее переросточное типа paste.debian.net можете закинуть?
> Конкретно эта штука - нет. Она решает одну конкретную задачу.
А в чем прикол выделить null из всех остальных ограничений? Я бы сказал что он наименьшая проблема т.к. за его дереференс при правильном определении обычно дает в репу само железо, кроме, разве что AVR и PIC каких.
> проверять разные вещи для const объектов в compile time. Возможно это
> можно сделать макросом самому, но я вряд ли смогу.
Ну вот на сях я это макросом смог, но сильно более жесткие ограничения чем компилер на самом деле внутрях видит, судя по тому как он лихо убил половину проверок, доказав что никогда столько не передается, и выкинув пару веток кода вот так влегкую.
> Вот что в данный момент раст может делать в compile time -
А там можно например тип enum сделать и рубать компил если параметр содержит что-то отличное от фиксированного значения опций? Это наверное катит только для небольшого числа значений, но все же?
> Насколько я знаю "Const generics" (https://github.com/rust-lang/rust/issues/44580)
Чудесатая штука. Хотя я бы сказал что трансмутации съели мой мозг... блин, глядя на это могу себе представить what it takes взять массив адресов и сказать что это у меня функции с прототипами (ничего особенного, типа bios-интерфейса к boot loader, чтобы основной код мог вызывать некоторые функции, хоть бут и отдал рули уже давно).
> его лимиты от 1 до 100. Но пока насколько я вижу оно еще не готово.
Вот это было бы весьма забавной фичой. Но глядя на те навороты я совершенно не уверен насколько это все safe и predictable все это может быть в именно махровой системщине.
> Плюс - ваш пример по фирмварю гироскутера это уже эмбедед, а не системщина.
> Тут можно начать спорить что такое системщина, а что нет,
> но предложу чтобы в этом вопросе каждый остался при своем мнении.
Я считаю что это частный случай системщины. Взбрык кернела или системной либы не сильно лучше взбрыка фирмвари. Особенно если оно там какой-нибудь поезд вело. А люди видите ли стали юзать компьютеры много для чего, в том числе и более компьютерообразные для более общей координации.
> Если это было про меню, то вроде показал,
То что его можно сделать похоже я догадался, но как это сделать хотя-бы настолько же симпатично (без левых кейвордов и проч в заполнении структуры) мне все же не особо очевидно.
> если про лимиты для параметров - то сорян, я не настолько крут. Но варианты решения
> есть выше.
Просто лимиты параметров ... ну вот напрягающая штука. Рантайм факапы мне не нравятся.
> Да, наверное они действительно ориентировались на универсальный язык. Поэтому там много
> высокоуровневых вещей вроде элементов функционального программирования.
Я заметил. И к сожалению это делает понимание того что происходит сильно менее тривиальным.
1) Чем сложнее и концептуальнее код, тем меньше людей в него въедет.
2) Чем сильнее закручены абстракции, тем больше шансов что их поймут неверно.
3) У плюсовиков это стало просто их стандартной граблей в результате.
4) В системщине хочется понимать что во что реально трансформируется. Вплоть до секвенсинга байтиков по шинам точным паттерном. Железки так сделаны.
> Но, в раст есть "режим" no_std, кмк это аналог freestanding.
Вот это похоже на правду.
> Если писать в этом режиме то оно вполне работает на микроконтроллерах.
Ага, вижу. По своему забавно. И все же, дорогие рустеры...
// Turn off the East LED
gpioe.bsrr.write(|w| w.br11().set_bit());
У меня это было бы
EAST_LED_ON;
или
EAST_LED_OFF;
...вместо той лабуды. Да еще с дико эффективным оперделением (1 запись в регистр, пара команд на асме будет). А макросы еще и позволят определять EAST LED как какой-нить
PIN_XDEF(EAST_LED, PORT_A, 4)
(на самом деле волшебную константу делает, где вкодирован и порт и пин, 100% compiletime и дико эффективно). Ахтунг, PIN_XDEF нестандартен - мое макро, идея у кого-то подсмотрена.
Или настройка пина после вон того могут быть так:
pin_setup(EAST_LED, OUTPUT_50MHZ_PUSHPULL). Да, без ооп, зато просто как топор, понятно даже дауну, и хотя это функция, компилер ухитряется на удивление заинлайнить только очень частный code path, столь же крутой как лобовая запись регистра константой. Заодно конкретные порты, биты и проч нигде не фигурируют. А высокоуровневые чуваки навернули ... какие-то дико странные абстракции и вышло что код на сях зело высокоуровневее, лаконичнее, и бинарь раз в эн меньше, не? :)
> PS: я не пытаюсь вас убедить бросить си и начать писать на
> расте. Скорее в том что добавление возможности писать драйверы на нем
> не сделает ядру хуже.
Может быть. Но честно говоря синтаксис у раста все же какой-то разлапистый и не очень консистентный на первый взгляд. А в вон том примере с мк абстракции сделали ... весьма странно, как по мне.
В любом случае, спасибо за insight, было интересно. И вообще это какжется первый рустер который более-менее в курсе inner working. Ну, не люблю черную магию сделаную богами. Системщина о том чтобы самому ее уметь...
