AZ
забавно что ты так воспринял
Бтв, NonEmptyVec это, конечно, очень классно, но в расте такой вот TypeDD это что-то за гранью фантастики.
Реализовать методы Vec для каждой с ним связанной обертки -- геморрой
Size: a a a
2020 April 20
AZ
так тебе не нужны все методы
AZ
ты пишешь только те которые нужно - head, ну и всё наверное
AZ
а дальше non_empty.into_vec().поехали_тут()
ML
Если NonEmptyVec -- это локальный для модуля тип, то да
AZ
для раста это чуть менее актуально
AZ
но например использовать хэшсеты более активно вместо проверок на дубликаты я начал и в шарповом коде, и вполне удобно
AZ
короч не проблема, если вектор распилить на трейты то и для нонэмпти их реализовать можно
ML
но например использовать хэшсеты более активно вместо проверок на дубликаты я начал и в шарповом коде, и вполне удобно
Ну это вроде как очевидная вещь и от языка не зависит
AZ
писать код только нужно в стиле
foo<T: IntoIter<u32> + Push<u32>>, но эт ладно ужML
короч не проблема, если вектор распилить на трейты то и для нонэмпти их реализовать можно
Проблема в том что коллекции в расте не распилены на трейты)
AZ
Ну это вроде как очевидная вещь и от языка не зависит
самые очевидные вещи обычно недооценены и не используются
AZ
Проблема в том что коллекции в расте не распилены на трейты)
но ведь это не сишарп да? Трейты можно снаружи навешать, не спрашивая авторов стд
AZ
вопрорс только чтобы они были более-менее стандартными, типа сердовских или typenum, но тут уже вопрос к распространенности
ML
но ведь это не сишарп да? Трейты можно снаружи навешать, не спрашивая авторов стд
Имхо, проблема такого подхода в том что ты будешь завязываться на какой-то свой особый путь, усложняя понимание своего кода.
Нужно взвесить стоит ли оно того
Нужно взвесить стоит ли оно того
ML
вопрорс только чтобы они были более-менее стандартными, типа сердовских или typenum, но тут уже вопрос к распространенности
Да, именно
ML
И вроде бы для такой задачи нужен GAT
AZ
да вроде нет
AG
