Extension traits #2812

LukeMathWalker · 2025-07-09T16:27:27Z

No description provided.

djmitche

looking good!

src/idiomatic/leveraging-the-type-system/extension-traits/method-resolution-conflicts.md

randomPoison

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

src/idiomatic/leveraging-the-type-system/extension-traits/extending-foreign-types.md

src/idiomatic/leveraging-the-type-system/extension-traits.md

src/idiomatic/leveraging-the-type-system/extension-traits/extending-other-traits.md

gribozavr · 2025-07-09T18:08:27Z

src/idiomatic/leveraging-the-type-system/extension-traits.md

+
+# Extension Traits
+
+In Rust, you can't define new inherent methods for foreign types.


Is "foreign type" a standard term to refer to types from other crates? I feel like it can be easily misinterpreted as "types defined in C++" (similar to "foreign functions"). Is there an alternative?

"Foreign type" and "foreign trait" are the terms used in the Rust reference when discussing orphan rules (see this section). So I'd say they are standard terms in this specific context.

Alternatively, we could use "new inherent methods for a type defined in another crate" as an alternative phrasing. It could get fairly verbose in the speaker notes.

ack. Maybe then briefly mention in the speaker notes what these terms mean, hinting that the instructor should maybe explain them. I don't think it is a given that the audience understands coherence rules and understands why it matters where the trait is defined.

Added in 17ba065

src/idiomatic/leveraging-the-type-system/extension-traits/extending-foreign-types.md

src/idiomatic/leveraging-the-type-system/extension-traits.md

gribozavr · 2025-07-15T11:44:18Z

src/idiomatic/leveraging-the-type-system/extension-traits.md

+
+<details>
+
+- Compile the example to show the compiler error that's emitted.


I think we should start by explaining what we want to achieve first: we want the user to be able to write something like mystr.is_palindrome(). Then transition to the obvious solution that does not work (the code snippet above). And then say that this is why we are using a more complex solution that does work.

Otherwise it might be confusing to some audience members: we are starting a new chapter by looking at a piece of code that does not compile (the impl block above), we want it to compile (why?..), but we actually wouldn't, instead we should do something else.

I restructured the flow a bit in 17ba065. What do you think?

gribozavr · 2025-07-15T11:47:12Z

src/idiomatic/leveraging-the-type-system/extension-traits.md

+  Highlight how the compiler error message nudges you towards the extension
+  trait pattern.
+
+- Explain how many type-system restrictions in Rust aim to prevent _ambiguity_.


You can raise the level of abstraction even higher.

One effective way to approach evaluating features in programming design is to ask "what if everybody did this?"

"I want to be able to add methods to someone else's type! I want to add an is_palindrome method to a string" - "Yes, but what if two people did this?"

Done in 17ba065

src/idiomatic/leveraging-the-type-system/extension-traits/method-resolution-conflicts.md

src/idiomatic/leveraging-the-type-system/extension-traits/trait-method-conflicts.md

…nding-foreign-types.md Co-authored-by: Dmitri Gribenko <[email protected]>

…od-resolution-conflicts.md Co-authored-by: Dmitri Gribenko <[email protected]>

gribozavr · 2025-07-16T13:19:15Z

src/idiomatic/leveraging-the-type-system/extension-traits/trait-method-conflicts.md

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


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.

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.

src/idiomatic/leveraging-the-type-system/extension-traits.md

randomPoison · 2025-08-01T19:03:34Z

src/idiomatic/leveraging-the-type-system/extension-traits/method-resolution-conflicts.md

+  Now `StrExt::trim_ascii` is invoked, rather than the inherent method, since
+  `&mut self` has a higher priority than `&self`, the one used by the inherent
+  method.


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.

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.

randomPoison · 2025-08-01T19:06:44Z

src/idiomatic/leveraging-the-type-system/extension-traits/method-resolution-conflicts.md

+  Point the students to the Rust reference for more information on
+  [method resolution][2]. An explanation with more extensive examples can be
+  found in [an open PR to the Rust reference][3].


Suggested change

Point the students to the Rust reference for more information on

[method resolution][2]. An explanation with more extensive examples can be

found in [an open PR to the Rust reference][3].

Point the students to the Rust reference for more information on

[method resolution][2].

I think we can just link to the reference, I don't think linking to an open PR is necessary. Eventually the things in that PR will (hopefully) land, so just linking to the reference is enough imo.

src/idiomatic/leveraging-the-type-system/extension-traits/extending-other-traits.md

randomPoison · 2025-08-01T19:49:03Z

src/idiomatic/leveraging-the-type-system/extension-traits/trait-method-conflicts.md

+- The compiler rejects the code because it cannot determine which method to
+  invoke. Neither `Ext1` nor `Ext2` has a higher priority than the other.
+
+  To resolve this conflict, you must specify which trait you want to use. For
+  example, you can call `Ext1::is_palindrome("dad")` or
+  `Ext2::is_palindrome("dad")`.
+
+  For methods with more complex signatures, you may need to use a more explicit
+  [fully-qualified syntax][1].


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.

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.

djmitche · 2025-08-08T01:44:25Z

src/idiomatic/leveraging-the-type-system/extension-traits/trait-method-conflicts.md

+  the same type may define a method with a name that conflicts with your own
+  extension method.
+
+  Survey the class: what do the students think will happen in the example above?


I think the approach of surveying the class is something specific to the instructor and situation. I would do this without prompting for small-group, in-person instruction, but for a large or shy group, or when using Zoom or Meet, it's not a very effective strategy (it results in lots of empty air).

So, it's a very minor point and not worth changing, but I think the question in the comment is sufficient here, and does not need repeating in the notes. Instructors will prompt from the comment if appropriate, or address it in a manner appropriate to the context and their teaching style.

LukeMathWalker added the deep_dives/idiomatic label Jul 9, 2025

LukeMathWalker force-pushed the extension-traits branch from 767976e to 8a1673c Compare July 9, 2025 17:06

LukeMathWalker changed the base branch from main to idiomatic-rust July 9, 2025 17:07

LukeMathWalker changed the base branch from idiomatic-rust to main July 9, 2025 19:03

Extension traits

be796c3

LukeMathWalker force-pushed the extension-traits branch 2 times, most recently from 9ad9fa7 to 9b50d50 Compare July 9, 2025 19:12

Reword

408962c

LukeMathWalker force-pushed the extension-traits branch from 9b50d50 to 408962c Compare July 9, 2025 19:12

djmitche reviewed Jul 9, 2025

View reviewed changes

src/idiomatic/leveraging-the-type-system/extension-traits/method-resolution-conflicts.md Outdated Show resolved Hide resolved

LukeMathWalker added 4 commits July 14, 2025 15:36

Use consistent terminology

1670b64

Extending other traits

bd1b26d

Trait method conflicts

06f251e

Shorter title

21a105e

LukeMathWalker marked this pull request as ready for review July 14, 2025 15:37

Mark trait method conflict as compile_fail

b64886c

LukeMathWalker requested a review from djmitche July 14, 2025 17:20

randomPoison requested changes Jul 14, 2025

View reviewed changes

Fix link

c36f7fe

gribozavr reviewed Jul 15, 2025

View reviewed changes

LukeMathWalker and others added 4 commits July 15, 2025 14:38

Update src/idiomatic/leveraging-the-type-system/extension-traits/exte…

5ab37d8

…nding-foreign-types.md Co-authored-by: Dmitri Gribenko <[email protected]>

Update src/idiomatic/leveraging-the-type-system/extension-traits/meth…

841bce5

…od-resolution-conflicts.md Co-authored-by: Dmitri Gribenko <[email protected]>

Update src/idiomatic/leveraging-the-type-system/extension-traits/meth…

aa2ab0f

…od-resolution-conflicts.md Co-authored-by: Dmitri Gribenko <[email protected]>

Update src/idiomatic/leveraging-the-type-system/extension-traits/meth…

63d3aa3

…od-resolution-conflicts.md Co-authored-by: Dmitri Gribenko <[email protected]>

gribozavr reviewed Jul 16, 2025

View reviewed changes

LukeMathWalker added 4 commits July 31, 2025 16:52

Address review comments

17ba065

Formatting and typos

d10c985

Elaborate further on the desired goal when extending other traits

771a37a

Extract bullet point into its own slide

b58a2a5

LukeMathWalker requested a review from gribozavr July 31, 2025 15:17

LukeMathWalker requested a review from randomPoison July 31, 2025 15:17

randomPoison requested changes Aug 1, 2025

View reviewed changes

djmitche approved these changes Aug 8, 2025

View reviewed changes


		# Extension Traits

		In Rust, you can't define new inherent methods for foreign types.


		<details>

		- Compile the example to show the compiler error that's emitted.

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

Extension traits #2812

Are you sure you want to change the base?

Extension traits #2812

Uh oh!

Conversation

LukeMathWalker commented Jul 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

djmitche left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

randomPoison left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

LukeMathWalker Jul 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

randomPoison left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

djmitche left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

LukeMathWalker commented Jul 9, 2025 •

edited

Loading

LukeMathWalker Jul 15, 2025 •

edited

Loading