Doesn't the Deref trait go against everything Rust stands for?

Treating Arc<T>.f() as T.f() is arguably unexpected behavior to the average non-rust programmer. Why should Arc<T> suddenly act like T only for method calls? Why shouldn’t Arc::new(1) + Arc::new(1) also work? It also allows the outer type’s methods to shadow the inner type’s methods, which is a very strange thing to see in a language that doesn’t allow overloading. The fact that Arc recommends this workaround of calling methods as if they were static and manually passing &self as the first argument makes it seem like this is undesired.

And on the contrary, C++ has the arrow operator which is much more explicit, doesn’t suffer from the name collision issues, and allows you to do this:

head→next→next.value += 1;

Instead of this:

(*(*head).next).value += 1;

Just seems like what Rust chose to do is the worst - verbose, inconsistent, implicit.

---

Comments

solidiquis1 • 23 points • 2023-08-30

1. Deref coercion is incredibly important for ergonomics. It’s so that we can effectively interact with all of the different types of smart pointers as though they were regular ol’ references e.g. allowing Box<T> where &T is expected.
2. Arc::new(1) + Arc::new(0) does not work because std::ops::Add takes self rather than &self. Keep in mind Arc<T> derefs to &T and not T.
3. Yes, I agree with you that deref coercion is black magic to Rust newcomers.

edit: spelling

[deleted] • 0 points • 2023-08-30

“Turned out to be the wrong choice…” is it really so controversial though? Yes, there’s a threshold in at which the ergonomic benefit isn’t worth the cost of the cognitive overhead but this hasn’t crossed it. Ergonomics is important in a modern language like Rust. You just need to familiarize yourself with the few sugary areas: Async, closures, and Deref.

solidiquis1 • 1 points • 2023-08-30

“Turned out to be the wrong choice…” is it really so controversial though? Yes, there’s a threshold in at which the ergonomic benefit isn’t worth the cost of the cognitive overhead but this hasn’t crossed it. Ergonomics is important in a modern language like Rust. You just need to familiarize yourself with the few sugary areas: Async, closures, and Deref.

simony2222 • 11 points • 2023-08-30

I think the point of Deref is actually to make the behavior of pointers consistent. That is, as you’ve pointed out, rust doesn’t have an -> operator and it kind of auto-decides whether to apply * on your pointer or not. Deref gives access to the same syntactic sugar to custom pointer types. Note that because of the implicit behavior it implies, the documentation strongly advises to implement this trait only on pointer-like types.

Although I agree that I find this confusing at times (especially with generics), and I wouldn’t mind calling a as_ref() (or equivalent) all the time to disambiguate things.

solidiquis1 • 1 points • 2023-08-30

I don’t think that’s a proper use of AsRef, however. AsRef is meant for converting between different types of references, thus the result of as_ref() could result in a type with completely different behavior e.g. calling as_ref on a String to get an OsStr.

In the case of an Arc we want the behavior of Arc as well as the underlying type’s behavior so Deref is appropriate.

mina86ng • 3 points • 2023-08-30

Saying that it’s against everything Rust stands for is a stretch but I agree that -> for method calls and field access would be better (possibly with additional AutoDeref marker trait for types which do want auto deref in those situations).

Trader-One • 3 points • 2023-08-30

In Rust, the Deref trait allows you to override the * operator. When you call a method on a type that implements Deref, Rust will automatically dereference the value for you as many times as needed to call the method on the inner type. This is called “deref coercion”.

this behavior only applies to method calls. Operators such as + are not methods. the + operator is associated with the Add trait. To make an expression like Arc::new(1) + Arc::new(1) work, you would need to implement the Add trait for Arc.

kernelmethod • 1 points • 2024-09-22

I know I’m resurrecting an old comment here, but is there any writing anywhere as to why Rust doesn’t do deref coercion on operators? It’s an interesting choice, since you could always opt into the coercion by calling `.add` explicitly.

Trader-One • 1 points • 2024-09-23

discuss it at rust forum.

puttak • -11 points • 2023-08-30

Rust by nature prefer productivity over explicitly.

tauphraim • 5 points • 2023-08-30

To explain the downvotes: this is just false. Rust usually prefers explicit, and OP noted that deref is an exception.

Also I don’t think rust aims at “productivity”. To me productivity is a negative term, used by people only concerned with outputting amounts of code, regardless of the readability and maintenability of said code.

puttak • 2 points • 2023-08-30

If Rust prefer explicit what about lifetime elision? What about trait object become 'static by default? A lot of things that implicit by Rust that cause headache for me when I still learning it.

tauphraim • 1 points • 2023-08-30

I guess there are more than one exception. For me, lifetime elision tended to make a first learning pass easier, if anything (you can assume it “just works” in simple cases), but someone else’s experience may differ. I think it’s not a feature aimed at making learning easier though.

puttak • 1 points • 2023-08-30

That why I said Rust prefer implicitly over explicitly. When you know how lifetime elision works you don’t need to type it and let Rust implicit for you. The problem is only who understand Rust will know this rule.

Another example of implicitly is an extreme type inference. You don’t need to specify the type for let most of the time and the compiler will pick it for you automatically, including type parameters.

glasket_ • 1 points • 2023-09-03

Preference for explicit doesn’t mean everything has to be explicit. Sometimes it’s beneficial to have implicit behaviors for readability or usability since explicit boilerplate can introduce a lot of visual and mental noise. I do agree that some of the implicit behaviors are kind of “footgunny” when you’re first learning, but I think in general Rust has struck a pretty good balance on what should be implicit, while still leaning towards making the user be explicit with more things than most other languages.

puttak • 1 points • 2023-09-04

Preference for explicit doesn’t mean everything has to be explicit.

Not true in my experience. See some examples from my previous comments. Another example is blanket implementation.

Sometimes it’s beneficial to have implicit behaviors for readability or usability since explicit boilerplate can introduce a lot of visual and mental noise.

That only applied when the reader is already know Rust.

while still leaning towards making the user be explicit with more things than most other languages.

Can you show some example of the other languages?

glasket_ • 1 points • 2023-09-04

Not true in my experience. See some examples from my previous comments. Another example is blanket implementation

I think you may have misunderstood what I meant here. “Preference for explicit doesn’t mean everything has to be explicit” isn’t something you can prove false. I’m saying that a language can prefer explicitness and still have parts of it be implicit, it just means the language will have a tendency to lean towards being explicit.

If you mean that you don’t think Rust prefers being explicit, then fair, but from the way the language’s designers talk they make things explicit then go back and add implicit behaviors for ergonomic reasons. To me, that’s a preference for being explicit while still being willing to allow implicit when it’s beneficial.

That only applied when the reader is already know Rust

Yeah, a common understanding is that explicit code favors novices while implicit code reduces the burden on veterans. The important thing is striking a good balance of having enough explicit to not make a write-only language while also not having too little implicit so that it isn’t overly-verbose boilerplate-laden code. This is part of the concept of language ergonomics.

As noted in that post though, some instances of implicit behavior aid learnability, with lifetime elision being the example used that I agree with. It reduces the burden on newcomers since they can typically ignore lifetimes until they hit a roadblock that forces them to deal with them explicitly.

Can you show some example of the other languages

• Unrestricted implicit type conversions, what most people point to as “bad implicitness”, is present in a lot of languages. C and C++ have an entire rule-set for determining how the implicit conversions will resolve. Rust chose to limit this solely to deref coercion, everything else must be explicitly cast.
• Ruby on Rails, notoriously, implicitly generates plurals of models. The plural of Cow? Kine.
• Haskell (primarily, there are some others) has an interesting notation called “pointfree” or tacit programming where function parameters themselves are implicit.

Rust, while still having implicit behaviors, tries to focus on taking explicit pieces of the language and shifting them towards implicitness in order to improve ergonomics without allowing the behaviors to cause problems.

• Deref coercion is the easiest to abuse (inheritance hacks, for example), but it’s still limited to dereferencing.
• Lifetime elision, which seems to be the bulk of what you dislike, primarily focuses on removing repetitive lifetime annotations like how type inference removes repetitive type annotations. It is noted to be a bit too implicit in some cases (reborrows can occur implicitly, as noted in the ergonomics blog post), but you can also enforce explicit lifetimes if necessary. Otherwise, it doesn’t cause problems that wouldn’t arise with explicit lifetimes.
• Personally, I don’t think of blanket impls as implicit. I feel like that stretches the definition of implicit a bit too much. Implicit implies that the language is doing something without input: types are inferred implicitly, lifetimes are elided implicitly, references autoderef implicitly on access, etc. But calling a blanket impl an implicit behavior feels off, like saying the addition operator working on all numbers is implicit. Dunno, to me that isn’t the same as the usual implied magic of implicit behaviors, it’s something that’s defined and you have to explicitly make use of the trait functions anyways.

Alright, this post has gotten too long. If you think Rust is focused on productivity at the expense of explicitness then there isn’t much I can do to convince you, but in my opinion the language designers clearly consider things carefully before moving away from fully explicit implementations; ergonomics/productivity are concerns, but I feel like they’re secondary to avoiding the pitfalls of “implicit magic.”

puttak • 2 points • 2023-09-04

Thanks for your time written this post.

poelzi • -9 points • 2023-08-30

I love defer because you can elegantly simulate inheritance by deref to the base class, which is an embedded struct

[deleted] • 8 points • 2023-08-30

This is cursed.

mina86ng • 1 points • 2023-08-30

And yet, people will keep doing it regardless of how much some of the Rust users hate inheritance.

poelzi • 1 points • 2023-08-30

I don’t understand the negative reaction of this pattern. I would link some advice how to implement a better API, in a more rusty way:

I have plugin system in which the implementations must implement some traits. There is also some shared functionality which each backend must implement. The backend struct just stores a pointed to the shared struct and I have a macro that implants deref to the shared struct.

I can easily share functionality between backends and can write obj.name() instead of obj.shared().name()

Is this a bad design and if yes, why ?

mina86ng • 0 points • 2023-08-31

I don’t understand the negative reaction of this pattern.

C++ does inheritance thus inheritance is bad. /s

glasket_ • 1 points • 2023-09-03

The unofficial Rust Design Patterns book gives a pretty good explanation of why most people don’t like seeing this pattern used in Rust. The tl;dr is that it’s not the intended use of Deref and it’s slightly different from and weaker than true inheritance so it causes some things to work in unexpected ways.

Most importantly this is a surprising idiom - future programmers reading this in code will not expect this to happen. That’s because we are misusing the Deref trait rather than using it as intended (and documented, etc.). It’s also because the mechanism here is completely implicit.

This pattern does not introduce subtyping between Foo and Bar like inheritance in Java or C++ does. Furthermore, traits implemented by Foo are not automatically implemented for Bar, so this pattern interacts badly with bounds checking and thus generic programming.

Using this pattern gives subtly different semantics from most OO languages with regards to self. Usually it remains a reference to the sub-class, with this pattern it will be the ‘class’ where the method is defined.

Finally, this pattern only supports single inheritance, and has no notion of interfaces, class-based privacy, or other inheritance-related features. So, it gives an experience that will be subtly surprising to programmers used to Java inheritance, etc.

Now for your specific implementation I sort of grasp what you’re doing, and it sounds like delegation, i.e. obj delegates the name function call to its shared member in your example, correct? If that’s the case, then you can use a facade and crates like delegate in order to map outer facade functions to the inner shared field’s methods. If I’m wrong then please correct me, I’m just not 100% on exactly what you’re doing without seeing the code.

phazer99 • 1 points • 2023-08-30

> It also allows the outer type’s methods to shadow the inner type’s methods, which is a very strange thing to see in a language that doesn’t allow overloading.

Rust supports overloading with traits, and that’s what Deref uses.

I agree implicit Deref’ing feels a bit magical at the beginning when most everything else in Rust leans towards explicitness. After a while you get used to it and, IMHO, the improved convenience is worth it in this case.

[deleted] • 1 points • 2023-08-30

golang does the same exact thing with structs. it works fine.

kohugaly • 1 points • 2023-08-30

It is the one place where Rust violates the explicit-over-implicit guideline to significantly improve ergonomics.

The Deref and DerefMut trait basically override the * dereference operator, to make smart pointers behave like actual pointers. Without it, you’d have to explicitly cast smart pointers to references, before calling methods of the inner type. This would be especially annoying for String and Vec<T> which coerce to str and [T] respectively. It would also be somewhat annoying for various kinds of mutex guards.

Rust basically unifies the . and -> operators into one, by deducing which one is applicable.

Rust’s ability to insert *& until it finds appropriate method can be used for limited form of method overloading. (for example for &T { fn my_method(self)...} takes precedence over for T {fn my_method(&self)...} but has the same function signature).

[deleted] • 1 points • 2023-08-30

Yeah this took me a while to wrap my head around back when I first learned Rust. It’s treated very lightly in the book and it’s very confusing to a newcomer.

You get used to it but I still dislike it.

[deleted] • 0 points • 2023-08-30

That page one should also say:

Thou shalt not implement Deref to emulate OOP inheritance.

buldozr • 1 points • 2023-08-31

That page one should also say:

Thou shalt not implement Deref to emulate OOP inheritance.