перевесит оверхед на лишнем коде, который придётся городить ради того, что бы обойтись без enum-ов или dyn-трейтов? Я думал там всего 1 байт.
GpioPin<Input> и GpioPin<Output> - не спроста разные типы с разными методами. если делать через enum, то в оверхед идёт код на определение инстанса и обработку ошибок. если это происходит в прерывании, это неприятно. не критично (пока), но неприятно. а ещё неприятно, что прерывание может запаниковать, такие вещи нелегко отлаживать на железе
1. определение инстанса это одна инструкция типа jne по тегу, это не оверхед а ерунда. Если у тебя там это не происходит в цикле на миллиард итераций 2. ошибки так и так нужно обрабатывать
> GpioPin<Input> и GpioPin<Output> - не спроста разные типы с разными методами. В Rust — это один тип с одним набором методов, параметризованный другим типом. 😊
ну строго говоря они мономорфируется в разные типы так что он прав
С разным набором методов? 😉
Конечно с разным
Откуда разница берётся?
impl GpioPin<Input>, impl GpioPin<Output>. Пути до методов могут быть разные, их имена, сигнатуры. В лучшем случае виртуализацию было бы только можно сделать через dyn.
если смотреть на компилятор (чего ты делать не хочешь) то разница в том что они по разным адресам находятся и разное делают. если смотреть с точки зрения теории типов про параметризвоанное одно другим то это все одно. Как всегда вопрос в определениях
Так человеку программировать нужно, а не выхлоп компилятора разгребать — если он не может в Rust сделать разный набор методов, что там по каким адресам лежит уже ничем не поможет. 🤷♀️😊
Падажжите... Откуда разные имена и сигнатуры (с точностью до тИповых параметров)?
full qualified name отличается. А без funext ты не скажешь что функции совпадают даже если они не завият от генерик аргументов
Формально — оно конечно, но мне кажется, это вовсе не тот "различный набор функций", о котором говорил топикстартер. 😊
Обсуждают сегодня