V
если ты сделаешь очень большой КОНСТАНТНЫЙ список тогда мб и да
Ещё можно боксом, и тоже рекурсии не будет, но не в компайлайме работать будет
Size: a a a
2020 August 20
В
это не хлист потому что он не позволяет хранить элементы разного типа и не требует матчинга через трейты
А, действительно.
Но я к тому, что тут в типе размер хранится и динамически с такой структурой особо не поработаешь
Но я к тому, что тут в типе размер хранится и динамически с такой структурой особо не поработаешь
AZ
А, действительно.
Но я к тому, что тут в типе размер хранится и динамически с такой структурой особо не поработаешь
Но я к тому, что тут в типе размер хранится и динамически с такой структурой особо не поработаешь
да не, можно работать, но определенные сложности офк возникнуть могут
OA
А, действительно.
Но я к тому, что тут в типе размер хранится и динамически с такой структурой особо не поработаешь
Но я к тому, что тут в типе размер хранится и динамически с такой структурой особо не поработаешь
Зато ты получил очередную порцию фП/МЛ поучений совершенно бесплатно
В
да не, можно работать, но определенные сложности офк возникнуть могут
А как ты с ним полностью динамически будешь работать, если у тебя добавление элемента тип изменяет?
AZ
А как ты с ним полностью динамически будешь работать, если у тебя добавление элемента тип изменяет?
dyn Node :)
В
dyn Node :)
Если ты сможешь сделать функцию
Box<dyn Node<T>> -> T -> Box<dyn Node<T>> то снимаю шляпуAZ
Ну в идрисе мог, в расте не уверен) Но может как-нибудь попробую
V
@Psilon а почему у трейта Node тайппараметр а не ассоциативный тип
В
V
Я бы больше спросил, зачем там вообще трейт
V
Потому что
impl<T> Node<T> for Nil {}Ну никто не мешает сделать Nil<T> я скорее логику написания спрашиваю
AZ
В
Я бы больше спросил, зачем там вообще трейт
Чтобы это был не
HList X)В
потому что может быть Node<i32> и Node<i64>
Так это будут
Cons<i32, _> и Cons<i64, _>V
потому что может быть Node<i32> и Node<i64>
Это не объясняет ничего, с ассоциативным типом, тоже могут быть разные ассоциативные типы в разных реализациях
AZ
Так это будут
Cons<i32, _> и Cons<i64, _>достаточно уметь в базовую логику. Генерики это \forall, а тайппараметр это \exists.
Очевидно что корректнее говорить \forall T. Node<T>, а не \exists T. Node<T>
Очевидно что корректнее говорить \forall T. Node<T>, а не \exists T. Node<T>
AZ
Это не объясняет ничего, с ассоциативным типом, тоже могут быть разные ассоциативные типы в разных реализациях
так реализация одна LinkedList должна работать с произвольным типом Т, а не с каким-то одним
AZ
Вопрос точно про Node а не Cons?
В
достаточно уметь в базовую логику. Генерики это \forall, а тайппараметр это \exists.
Очевидно что корректнее говорить \forall T. Node<T>, а не \exists T. Node<T>
Очевидно что корректнее говорить \forall T. Node<T>, а не \exists T. Node<T>
Для меня не очевидно(
Я бы так сделал:
Я бы так сделал:
trait Node {
type Item;
}
struct Nil<T>(PhantomData<T>);
impl<T> Node for Nil<T> {
type Item = T;
}
struct Cons<N: Node> {
head: N::Item,
tail: N,
}
impl<N: Node> Node for Cons<N> {
type Item = N::Item;
}
(playground)