Problem in the std::fs::File docs? Or a problem with me?


#1

Code sample: https://play.rust-lang.org/?gist=5b5c5397da7a547aeee6&version=stable

As far as I can tell, this is the same as the example code in the std::fs::File docs

But I can’t get that to compile locally (using version 1.2.0) or in play.rust-lang. Is this a problem with the docs, or me?


Try! and File::create - misunderstanding E0308
#2

The example is fine, you just can’t put it into main() as it is.

The main function must have () return type, but the try! macro requires that the function returns a Result<A, B>. The usual solution is to let main call an inner function that returns the Result.


#3

Yeah, after clicking the doc link that showed the code in play.rust-lang I was able to puzzle that out. Thanks for the help!

This is one of those things where the documents only really make sense if you already know what you’re doing, I think.


#4

Yes, try! should be described very early in tutorials. (I don’t know if it is, currently.)


#5

Yeah, the issue is, if you include the text of the wrapping function, it really distracts from the important part, the example. But if you don’t, it can be confusing to people who haven’t used try!. We’ve made the decision in this case to go with the “more clear example” route, but I would also like to see if we can’t get try! to have a better error message, to help out.


#6

I see the problem with try! macro very often. The topic is at least second today I read about misunderstanding try!, excluding yet another kind-of-RFC with yet another try catch proposal.

This means either we have some deficiency in the docs, as they should explain this basic things better, or it is calling for a FAQ page, as a lot of things related to try! and error handling are repeated a lot on this forum.


#7

It feels like it should be possible for the compiler to issue hints for “popular” type mismatches, like () != Result<_, _> or f32 not implementing Ord.


#8

I’m not sure hardcoding some specific cases in compiler is a good style.


#9

I would argue that Rust already has cases like this, like the “x is not an Iterator, maybe call iter() or such” message.

And for a good reason: the impact on perceived “friendliness” of the language can be huge, especially in the face of “unfriendly” messages like lifetime stuff.