5 ms·
i prefer the Before one, it is clear what it does, it's branching, common, even in plain english or any latin language the second, that magic is not clear, i'l
by Shadonototro 6y ago
i prefer the Before one, it is clear what it does, it's branching, common, even in plain english or any latin language
the second, that magic is not clear, i'll keep using the Before personally
- momothereal 6y agoIMO it depends if you're already in a chaining context. I wouldn't use it in a simple if-else branch, but it also removes the need to use if-else when you're already in a 10-function long chain. Before: if a.b().c().d().e().f() { Some(g().h().i()) } else { None } Now: a().b().c().d().e().f().then(|| g().h().i()) Even better if you have multiple boolean returns in the chain.
- csomar 6y agoThe naming can be confusing since "then" is usually used for async operations.
- steveklabnik 6y agoThat ship had already sailed in Rust https://doc.rust-lang.org/stable/std/?search=then https://doc.rust-lang.org/stable/std/?search=then
- hobofan 6y agoOption and Result already have a `and_then` in addition to the futures methods you mention, so it should just always be assumed that then/and_then have slightly different meanings depending on the context.
- deleted 6y ago[deleted]
- alfiedotwtf 6y agoI used to like explicit if/then and using match, but chaining really does reduce code. It can sometimes take a while to golf it down, but damn is it satisfying when it’s all so compact. Followed by a `cargo fmt` and it feels way more elegant than branching