Code change:
Part of Here's what needs to be done to close out this issue: is great, but has a lot of abbreviations, so the wording could be cleaned up a bit. should compare itself to , and should show a sample implementation. needs far better docs, as it is one of the most misunderstood traits in Rust. Specifically it should talk about its relationship with . It also needs an example implementation. needs a lot of work; it should talk about its usage in , it should show an example implementation, and general improvement. is mostly fine, but "generic impls" should say "implementations" and it should be above examples.
I am happy to mentor anyone who wants to tackle this issue.
I would be keen to give this one a go I'm interested in understanding this section better.
Awesome, ! Let me know if I can help you help me in any way
Hey , Just a couple of questions: the issue description for the trait you say to have the generic implementations above the examples, It turns out all of the traits have the examples above the generic implementations. Should I move the generic implementations above the examples for all of the traits? adding sample implementation do you like to make a generic example or use a common example from the std lib? I only ask because I have become familiar with through the usage within the package in creating paths and was thinking of using this as an example. What are your thoughts? relationship with is where I am having a bit of trouble explaining this concisely. Are we wanting to have a brief summarization of the section in the book and do we need to reciprocate or align with the documentation for the trait? I only ask as I feel to explain the difference I am describing the trait a bit and do not want to introduce a second differing description. Thanks :smile:
Hey ! Yes, that'd be great! Ideally, we'd have both: one extremely simple example for people to be able to copy/paste, and one more realistic example. Feel free to submit one or both yes it's tough! The second edition of the book does not have that chapter; synchronizing these API docs is the right way to go
OK great :smile: I will hopefully have something in today to start picking apart. :+1:
Hey , I had a look at the [RFC] mentioned in the contribution guide and couldn't find anything on the guidelines for line length. I only ask as one of the Travis builds failed due to the line exceeding 100 chars, so was wondering what I should be aiming for. Thanks again! :smile: [RFC]:
Standard library docs are wrapped to 80 characters. :)
This is now done!

Related discussion:
text: //! Like many traits, these are often used as bounds for generic functions, to //! support arguments of multiple types. //! <ins> //! - Impl the `As*` traits for reference-to-reference conversions //! - Impl the `Into` trait when you want to consume the value in the conversion //! - The `From` trait is the most flexible, usefull for values _and_ references conversions //! //! As a library writer, you should prefer implementing `From<T>` rather than //! `Into<U>`, as `From` provides greater flexibility and offer the equivalent `Into` //! implementation for free, thanks to a blanket implementation in the standard library. //! //! **Note: these traits must not fail**. If the conversion can fail, you must use a dedicated //! method which return an `Option<T>` or a `Result<T, E>`. //! //! # Generic impl //! //! - `AsRef` and `AsMut` auto-dereference if the inner type is a reference //! - `From<U> for T` implies `Into<T> for U` //! - `From` and `Into` are reflexive, which means that all types can `into()` //!   themselves and `from()` themselves //! </ins> //! See each trait for usage examples. #![stable(feature = "rust1", since = "1.0.0")]