Uncomment fn() names to make ?-examples work

[perlun]

I noted tonight that using the examples straight away, e.g. in your main method or in any other method returning a non-std::io::Result value fails, because of reasons mentioned in rust-lang/rfcs#1937. The full example was found, commented out in the code.

I suggest uncommenting these parts of the examples, so that the examples are more "copy-pasteable" and show the true requirements for using them. The compilation errors I got wasn't enough to make me realize what the problem was:

error[E0277]: the trait bound `std::string::String: std::ops::Try` is not satisfied

---

(Thanks to the helpful people at #rust-beginners who helped me debug it; it was obvious once you knew the prerequisites for using the ? operator.)

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[Wolvereness]

I think this would be better suited to a toggle for showing the full example across the entire doc-tool's output.

[steveklabnik]

Historically, this decision was made on purpose. These examples will be more copy/pastable with the new ? in main stuff, and with this boilerplate, it really is distracting to the actual example.

Furthermore, @Wolvereness is right; I'd like to see a toggle like we have in mdbook.

I appreciate you caring about the examples, but since this was a conscious decision, I'm going to give this a close. Changing this at this point would require a docs RFC, and if you feel very strongly about this, I'd suggest going that route. Thank you!

[perlun]

@steveklabnik

I appreciate you caring about the examples, but since this was a conscious decision, I'm going to give this a close. Changing this at this point would require a docs RFC, and if you feel very strongly about this, I'd suggest going that route.

No, i think @Wolvereness point makes sense; adding a feature for this to the website to allow it globally (with it being enabled or disabled by default, ideally persisting via cookie or local storage) would make even more sense. The important thing for me is to help beginners to avoid newbie mistakes, which is easy with the current approach. Even after supporting ? in main, we might still have people trying this out in another function, not realizing that they need to wrap the return value in that case etc.

I can create a GH issue about it to facilitate some discussion around it before implementing it. Should I route it to this repo or somewhere else?

[steveklabnik]

A thread on internals is the best place for discussions.

…

On Mon, Aug 14, 2017 at 7:48 AM, Per Lundberg ***@***.***> wrote: @steveklabnik <https://github.com/steveklabnik> I appreciate you caring about the examples, but since this was a conscious decision, I'm going to give this a close. Changing this at this point would require a docs RFC, and if you feel very strongly about this, I'd suggest going that route. No, i think @Wolvereness <https://github.com/wolvereness> point makes sense; adding a feature for this to the website to allow it globally (with it being enabled or disabled by default, ideally persisting via cookie or local storage) would make even more sense. The important thing for me is to *help beginners* to avoid newbie mistakes, which is easy with the current approach. Even after supporting ? in main, we might still have people trying this out in another function, not realizing that they need to wrap the return value in that case etc. I can create a GH issue about it to facilitate some discussion around it before implementing it. Should I route it to this repo or somewhere else? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#43811 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABsilzbX6G6e5CUnKDGDRiiyqrCzhnrks5sYDQcgaJpZM4O1GhH> .