AZ
объясни
сигнатура
and_then у футурыfn and_then<F, B>(self, f: F) -> AndThen<Self, B, F>
where
F: FnOnce(Self::Item) -> B,
B: IntoFuture<Error = Self::Error>,
Self: Sized,Size: a a a
2020 March 25
AZ
AZ
он не совпадает по сигнатуре с монадным
AZ
Self и AndThen - разные типы
AZ
значит это не флатмап
p
сложна
AZ
у флатмапа должно быть
fn and_then<F, B>(self, f: F) -> Self<B>
fn and_then<F, B>(self, f: F) -> Self<B>
AZ
сложна
ничего сложного
AZ
у флатмапа должна быть сигнатура такая, что слева и справа один тип
AZ
а по фкту разные
AZ
почему работает в хаскелле?
p
у флатмапа должно быть
fn and_then<F, B>(self, f: F) -> Self<B>
fn and_then<F, B>(self, f: F) -> Self<B>
ага, и эта сигнатура не подразумевает ленивость же
AZ
потому что в хаскелле сигнатура:
fn and_then<F, B>(self: Box<dyn Future>, f: F) -> Box<dyn Future>AZ
вот мы и приходит к вопросу выразительности и гц
AZ
раст заставляет юзать боксы аккуратно и явно
AZ
но с явными боксами монадического интерфейса не выйдет в любых случаях, сложнее простейших ейзеров и мейби
AZ
но даже если мы напишем явные боксы - гц умеет боксы лишние выкидывать, он очень хорошо умеет много памяти в кучи аллоцировать и т.п.
AZ
в расте же приложение умрет
AZ
в мейне был пример ,челик на хаскелле лучший перформанс получил, потому что у него было забокшенное дерево
AZ
такие дела