Extension traits

[LukeMathWalker]

No description provided.

[djmitche]

looking good!

[randomPoison]

This looks good! I only have a couple of minor comments, but on the whole I like it :)

[gribozavr]

Suggested change

	- The extended trait may, in a newer version, add a new trait method with the
	same name of our extension method.
	- Another extension trait may, in a newer version, add a new trait method with the
	same name as our extension method.

[LukeMathWalker]

Both cases are actually possible, so I reworded the paragraph to account for both in 17ba065

[randomPoison]

I think we might want to change the examples in this section to not be on &str, since implementing a trait on a reference leads to confusing behavior around method resolution (which I talk about in more detail in one of the comments here). I think things would be less confusing if we used a non-reference type like i32 or struct Foo.

[randomPoison]

I don't think this is an accurate explanation of what's happening here. The reference explicitly states (in the info box in that section) that &self methods have higher priority than &mut self methods.

I think the reason why the &mut self version gets higher priority here is that the receiver expression is &mut &str. If I'm understanding the reference's explanation of method resolution correctly, this means that when it builds the list of candidate receiver types, &mut &str is the first candidate type in the list. It's then choosing between the inherent &str method and the &mut &str method coming from the trait, and the latter wins because it's the actual type of the expression &mut " dad ".

I think the confusion here is because we're implementing the trait on on &str, which is already a reference type. If I change the trait to be implemented on str directly (i.e. impl StrExt for str), when when I change the method to take &mut self the inherent method still gets called (exmple in the playground). Part of the reason for this is because when we do (&mut " dad ") we're not getting a &mut str, we're getting a &mut &str.

I think things would be a lot less ambiguous if we were demonstrating this on a regular, non-reference type such as i32 or struct Foo.

[LukeMathWalker]

Thanks for looking at it closely!
Re-reading through it, and cross-referencing with the RFC, I agree with your interpretation as to why things play out as they do in terms of precedence. I'll rework the example to something simpler.

[gribozavr]

+1, I'd be happy if we explained a basic rule that people can remember, and simply mention that while the Rust language has rules to disambiguate in other cases, the rules are quite complex to remember and apply, and we'd rather not write code that depends on them.

[randomPoison]

It's probably worth showing the full syntax to students, since sometimes Trait::method(foo) isn't enough. Specifically, if the compiler can't infer the type of foo then it won't be able to resolve which type's trait implementation to use. In those cases you'd have to write <Type as Trait>::method(foo). That syntax can be surprising for people new to the language (I know I was confused the first time I saw it), so I think showing it here (and explaining when it's necessary) would be good.

[gribozavr]

+1, that would be a good thing for the instructor to demonstrate. Please add a bullet point with the prompt for the instructor.

[djmitche]

This looks great to me. The note below is stylistic and relates only to the speaker notes, so feel free to treat it as a mild preference at most.

[gribozavr]

+1, that would be a good thing for the instructor to demonstrate. Please add a bullet point with the prompt for the instructor.

[gribozavr]

@LukeMathWalker I left another round of comments, but please don't be discouraged - this section looks very good and the comments are mostly minor. Please work through resolving the comments, rebase the PR to resolve conflicts with main, and merge. You have my LGTM.