Type Option. The 2014 version.[1] The 2016 version.[2]
(Coming soon, the "?" operator.[3])
Here's an example of excessive cleverness [4]:
fn main () {
let number: f64 = 20.;
// Perform a pipeline of options.
let result = Some(number)
.map(inverse)
.map(double)
.map(inverse)
.and_then(log)
.map(square)
.and_then(sqrt);
// Extract the result.
match result {
Some(x) => println!("Result was {}.", x),
None => println!("This failed.")
}
}
The designers of Go knew when to stop. The designers of Rust don't.
[1] https://web.archive.org/web/20140814230239/http://doc.rust-l...
[2] https://doc.rust-lang.org/std/option/enum.Option.html
Nor are you forced to use code like the excessively clever version you talk of. People who are used to monadic programming have the choice to.
You're making the same crappy arguments like a broken record. I'm not having the same tired old discussion again.
'.map' maps over the option. '.and_then' is the monadic bind operation, that you find in pretty much every modern programming language (frequently named 'flatMap'; even Java has this nowadays).
They're not opaque. Templates are more opaque because of the lack of self documenting bounds, perhaps (i still wouldn't call them opaque, just more so than Rust generics)
This is the millionth time you're repeating that garbage about imperative control flow. It boils down to a use of closures in a few stdlib functions. We've had this argument before, the essence of your point is that it is different from C. Of course there is a learning curve but that is there the other way too. Once you get used to it the control flow is pretty straightforward. And in most cases you can avoid the closures and write your if or loop manually.