These are chat archives for rust-lang/rust
matchit, use the if/let syntax, or use something like
foo >> bar >> bazor
foo >>= bar >>= bazis quite handy and keeps the 'noise' of error handling down. Kind of like exception handling in Python or other languages.
>>, although it is kinda noisy
if let Some(x) = optis a nice alternative when you need side effects
try_opt!in some crate. Which is the same
?to be extended to handle other types than Result in the future. after all, its RFC initially described the trait-based approach
foo >>= bar x >>= baz y is both concise and clear once you know what
foo.and_then(|x| blah).and_then(|y| blarg) is denser. The reader does not have whitespace and symbols to make it easier and faster to comprehend.
Sure some new lines help
foo.and_then(|x| blah) .and_then(|y| blarg)
But when it comes time to refactor the dev has to rewrite the lambdas, change out the Monad helper functions, etc.
Monadbecause I trust people have seen it. But I am not spouting out isopolymertantrimetric gobbledy gook :-)
foo >>= bar x >>= baz y
can also be written in this format (which is really sugar for the above)
do v <- foo z <- bax x v baz y z
Which looks very imperative
letin front of those variable assignments
structcontaining data coupled with functions that act on that data. In FP
classis often used like
traitis in Rust.
That would be the most readable C ever XD
I had to ask if it was weird to dereference the
this pointer and use operators on it. I had overloaded the
operator and I was implementing the
at function which is
operator with bounds checking and I wrote
(*this)[idx] and for some reason, that just felt so wrong to me...
thisis expected when operating on class local bits. I much prefer the explicit self of Python, Rust, and others.
Errtake a value too.