Poll: try! syntax changes

21

Not just as and_then() sugar, but as sugar for .map_err(From::from).and_then(). That coupled with the existing try! could let you turn that example into the following (though note that you would also have to implement From properly for MyErr, however I think that's true of all of the proposals):

fn file_double<P: AsRef<Path>>(file_path: P) -> Result<i32, MyErr> {
    let mut contents = String::new();
    try!(File::open(file_path)?.read_to_string(&mut contents));
    Ok(try!(contents.trim().parse::<i32>()) * 2)
}
22

I guess I didn't read carefully enough.

23

I'm agree.

Also I like try!, but I don't want to have syntax alternatives. Because I will use it rare as try!. I use own do_it_well! macro which is more powerful than try! for my tasks. Syntax changes I see useless. Own macro is better.

24

I feel like the existing RFC for try ... catch blocks and ? is really what I want:

https://github.com/glaebhoerl/rfcs/blob/trait-based-exception-handling/active/0000-trait-based-exception-handling.md

It basically lets you delimit try! expressions with a block instead of returning, which actually feels less magical than needing a Result as a return type, and lets you try in main.

25

F# lets you build ad-hoc, named "do-syntax" extensions to the language by specifying "computation expression" builders. In Rust this would amount to just implementing a Builder trait.

But as one Rust user has pointed out, there a million more problems to monads than just having HKTs. I think the most general solution would be adding constraint kinds and higher kindred types but obviously this is worth discussing more. Also, I don't think a monad trait is actually all that useful. Someone should point me in the direction of a useful abstraction built over monads in general that isn't a monad transformer or a "hot-pluggable" mutation strategy (i.e. using IO or ST for your vectors in Haskell), since Rust is not an effect tracking language.

In any case, HKTs are a massively desired feature, which will beget monadic syntax extensions, which are the more general abstraction, so I think it would be unwise to jump on a try keyword or make optional types first class in the syntax the way Swift has done. Perhaps we will not be using Results or Options 5 years from now?

2 Likes
26

In that case, std is going to look a bit anachronistic.

27