Add `derive(Deref)` RFC #3911

GuillaumeGomez · 2026-01-22T15:59:17Z

This PR introduces discussion about adding another derivable trait: Deref (follows-up the newly added derivable trait From).

Rendered

text/0000-derive-deref.md

programmerjake · 2026-01-22T17:01:36Z

text/0000-derive-deref.md

+# Unresolved questions
+[unresolved-questions]: #unresolved-questions
+
+Should we also derive `DerefMut` with the same conditions as described here?


I often don't want DerefMut on something that implements Deref, so I don't think derive(Deref) should implement DerefMut, however I think having a separate derive(DerefMut) would be awesome.

One thing to consider with derive(DerefMut) is what happens when you implement Deref manually but derive(DerefMut) -- should it error when Deref::Target isn't the expected type? If you don't explicitly check for it, the deref_mut() could end up coercing the return type to fit. e.g.:

#[derive(DerefMut)] // should this error or rely on silent coercion of String to str? pub struct S(String); impl Deref for S { type Target = str; fn deref(&self) -> &str { &self.0 } }

You made me realize I formulated my sentence badly. I meant adding a new DerefMut derivable item with the same condition as described for Deref.

And it's exactly for such cases that I didn't want to put DerefMut in this RFC. :)

I clarified my sentence and also added the problem you mentioned with its example.

it should be noted there's already this kinda incongruity possible with PartialOrd and Ord, and, to a lesser extent, (Partial)Eq. i think we lint in this case but can't remember off the top of my head.

it should be noted there's already this kinda incongruity possible with PartialOrd and Ord, and, to a lesser extent, (Partial)Eq. i think we lint in this case but can't remember off the top of my head.

yes, except none of those can cause a type error or require type coercion. Deref is different because it has an associated type that DerefMut uses.

I think one example is enough, no?

programmerjake · 2026-01-22T17:21:40Z

rfcs/README.md

Lines 133 to 134 in 11ca03e

    
           **Specifically, do not squash or rebase commits after they are visible on 
        
           the pull request.**

GuillaumeGomez · 2026-01-22T21:37:48Z

@programmerjake Dully noted.

kpreid · 2026-01-22T23:16:31Z

text/0000-derive-deref.md

+
+Using `#[derive(Deref)]` on unions produces a compilation error.
+
+# Drawbacks


One disadvantage of defining #[derive(Deref)] as this RFC does is that it will do the wrong thing for smart pointer types.

#[derive(Deref)] struct MyPtr1<T>(Box<T>);

MyPtr1 will deref to Box<T> rather than T, which is likely harmless but may reveal an implementation detail, increase the number of *s needed, or in the case of derive(DerefMut), allow breaking an invariant.

#[derive(Deref)] struct MyPtr2<T>(*mut T);

MyPtr2 will dereference to a raw pointer which can't be safely dereferenced, whereas the intent would presumably be to dereference to T.

I don’t think that this is a reason not to provide this derive at all, but it is something that I think should be noted explicitly as a hazard. (The #[deref(forward)] attribute proposed below would allow getting the right behavior from MyPtr1, but users would still need to know to add it.)

Adding to that, #[deref(forward)] should raise a compile error when used with raw pointers (or any type unsafe to Deref if we add more).

Or, we could make an unsafe attribute for that case

kpreid · 2026-01-22T23:17:02Z

text/0000-derive-deref.md

+# Drawbacks
+[drawbacks]: #drawbacks
+
+While this does enable more Rust code to "just work", it also means that we should be able to produce high-quality error messages in the compiler, as it is trivial to detect how many fields a struct or an enum variant has.


I don’t understand how this paragraph describes a drawback. Did it belong to a different section?

I think they meant that we need to be careful making the error messages

Yes, I'll reword it to make it more obvious.

kpreid · 2026-01-22T23:18:32Z

text/0000-derive-deref.md

+    #[derive(derive_more::Deref)]
+    struct Point(#[deref] i32, i32);
+    ```
+- You can use the `#[forward]` attribute to use the `Deref` target of the current derefed item.


Suggested change

- You can use the `#[forward]` attribute to use the `Deref` target of the current derefed item.

- You can use the `#[deref(forward)]` attribute to use the `Deref` target of the current derefed item.

kpreid · 2026-01-22T23:22:04Z

text/0000-derive-deref.md

+# Future possibilities
+[future-possibilities]: #future-possibilities
+
+## `#[forward]` attribute


Consistency:

Suggested change

## `#[forward]` attribute

## `#[deref(forward)]` attribute

kpreid · 2026-01-22T23:22:56Z

text/0000-derive-deref.md

+#[deref(forward)]
+struct MyBoxedInt(Box<i32>);


I think it would be a better syntax if the #[deref(forward)] attribute were placed on the field being dereferenced exactly like #[deref] is. That way, #[deref(..)]’s placement always has a single meaning and forward is a modifier to it rather than something different.

Suggested change

#[deref(forward)]

struct MyBoxedInt(Box<i32>);

struct MyBoxedInt(#[deref(forward)] Box<i32>);

Yeah, that also solves all possible ambiguities. Good idea!

kpreid · 2026-01-22T23:23:26Z

text/0000-derive-deref.md

+impl derive_more::core::ops::Deref for MyBoxedInt {
+    type Target = <Box<i32> as derive_more::core::ops::Deref>::Target;
+    #[inline]
+    fn deref(&self) -> &Self::Target {
+        <Box<i32> as derive_more::core::ops::Deref>::deref(&self.0)


Suggested change

impl derive_more::core::ops::Deref for MyBoxedInt {

type Target = <Box<i32> as derive_more::core::ops::Deref>::Target;

#[inline]

fn deref(&self) -> &Self::Target {

<Box<i32> as derive_more::core::ops::Deref>::deref(&self.0)

impl ::core::ops::Deref for MyBoxedInt {

type Target = <Box<i32> as ::core::ops::Deref>::Target;

#[inline]

fn deref(&self) -> &Self::Target {

<Box<i32> as ::core::ops::Deref>::deref(&self.0)

programmerjake · 2026-01-23T02:22:42Z

text/0000-derive-deref.md

+        type Target = $t;
+
+        fn deref(&self) -> &Self::Target {
+            self.0


Suggested change

self.0

&self.0

programmerjake · 2026-01-23T02:23:09Z

text/0000-derive-deref.md

+        type Target = $t;
+
+        fn deref(&self) -> &Self::Target {
+            self.$n


Suggested change

self.$n

&self.$n

programmerjake · 2026-01-23T02:23:31Z

text/0000-derive-deref.md

+        type Target = $t;
+
+        fn deref(&self) -> &Self::Target {
+            self.$f


Suggested change

self.$f

&self.$f

programmerjake · 2026-01-23T02:33:05Z

text/0000-derive-deref.md

+# Future possibilities
+[future-possibilities]: #future-possibilities
+
+## `#[forward]` attribute


It could also be handy to allow multiple deref operations:

#[derive(Deref)] // generated Deref::Target = T pub struct CowArc<'a, T> { #[deref(forward = 2)] // maybe `#[deref(count = 2)]`? v: Cow<'a, Arc<T>>, }

I don't understand what you're suggesting.

I suppose they mean that #[deref(forward = n)] would deref that field n times

Their example would deref to T rather than Arc or Cow

Oh I see. Adding this suggestion then.

…to dereference more than once

programmerjake · 2026-01-23T13:42:00Z

text/0000-derive-deref.md

+}
+```
+
+In case we want to deref more than once, we could allow a non-null positive integers value:


Suggested change

In case we want to deref more than once, we could allow a non-null positive integers value:

In case we want to deref more than once, we could allow a positive integer value:

null is an unusual way of describing zero. also zero doesn't count as a positive integer.

GuillaumeGomez force-pushed the derive-deref branch from 5c730be to 71ef5a8 Compare January 22, 2026 15:59

GuillaumeGomez added the T-lang Relevant to the language team, which will review and decide on the RFC. label Jan 22, 2026

GuillaumeGomez force-pushed the derive-deref branch 2 times, most recently from 1aeaa35 to db0edb1 Compare January 22, 2026 16:22

ionicmc-rs reviewed Jan 22, 2026

View reviewed changes

text/0000-derive-deref.md Outdated Show resolved Hide resolved

GuillaumeGomez force-pushed the derive-deref branch from db0edb1 to bd87e29 Compare January 22, 2026 16:39

programmerjake reviewed Jan 22, 2026

View reviewed changes

Add derive(Deref) RFC

3206f4c

GuillaumeGomez force-pushed the derive-deref branch from bd87e29 to 3206f4c Compare January 22, 2026 17:09

kpreid reviewed Jan 22, 2026

View reviewed changes

programmerjake reviewed Jan 23, 2026

View reviewed changes

GuillaumeGomez added 2 commits January 23, 2026 12:00

Fix code examples and add new drawback case for raw/smart pointers

d8232b6

Add possibility to add an integer for the deref(forward) attribute …

afa2fa2

…to dereference more than once

programmerjake reviewed Jan 23, 2026

View reviewed changes

Improve wording for positive integers

9897e01


		Using `#[derive(Deref)]` on unions produces a compilation error.

		# Drawbacks

	- You can use the `#[forward]` attribute to use the `Deref` target of the current derefed item.
	- You can use the `#[deref(forward)]` attribute to use the `Deref` target of the current derefed item.

	#[deref(forward)]
	struct MyBoxedInt(Box<i32>);
	struct MyBoxedInt(#[deref(forward)] Box<i32>);

	In case we want to deref more than once, we could allow a non-null positive integers value:
	In case we want to deref more than once, we could allow a positive integer value:

Add derive(Deref) RFC #3911

Are you sure you want to change the base?

Add derive(Deref) RFC #3911

Conversation

GuillaumeGomez commented Jan 22, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

GuillaumeGomez Jan 22, 2026 • 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!

soqb Jan 22, 2026 • 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!

programmerjake commented Jan 22, 2026

Uh oh!

GuillaumeGomez commented Jan 22, 2026

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!

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!

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!

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!

programmerjake Jan 23, 2026 • 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!

ionicmc-rs Jan 23, 2026 • 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!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Add `derive(Deref)` RFC #3911

Add `derive(Deref)` RFC #3911

GuillaumeGomez commented Jan 22, 2026 •

edited by rustbot

Loading

GuillaumeGomez Jan 22, 2026 •

edited

Loading

soqb Jan 22, 2026 •

edited

Loading

programmerjake Jan 23, 2026 •

edited

Loading

ionicmc-rs Jan 23, 2026 •

edited

Loading