Book: ch17.02: Mentioning duck typing with traits is confusing

[ford-prefect]

Mentioning duck typing (at least in the way it is currently done) w.r.t. duck typing could be confusing to users.

In my mind, traits are practically the opposite of duck typing. With traits you're explicitly stating that you expect a duck and the type needs to implement the duck trait to qualify, whereas the name "duck typing" implies that you need to inspect behaviour (walks like, talks like) to conclude that it's a duck. and this cannot be declaratively stated by the type itself.

[carols10cents]

The reason traits are like duck typing are that in both cases, you don't care about the actual type of the instance you have, you only care that it has the behavior you need.

Does that make sense or is that still confusing? If it makes sense, we can definitely add more text to point out the aspects of duck typing that are similar, and clarify that you don't need to check for the behavior in your code because the compiler has already done so with the trait.

[ford-prefect]

Hmm, it does make sense in that way. Perhaps it makes sense to point out the ways in which it is similar and how it's different (safer)?

[steveklabnik]

I also had originally flagged this for review, but didn't mind our final wording. I think maybe a small expansion would make sense....

[carols10cents]

Sounds good! I'll work on this next time we get this chapter from nostarch for editing :)

[nodakai]

Rust employs nominal subtyping around traits (as opposed to structural subtyping which is the closest thing to what's called duck typing in dynamically typed language communities)

• https://www.reddit.com/r/rust/comments/309qv0/is_rusts_type_system_structural_or_nominative/

@nrc I saw your name in the thread.

It would have made some sense to call Rust a "duck typing" language if struct Button could be put into Screen just by defining a draw() method within the plain impl Button syntax; in actuality Rust requires us to use the impl Draw for Button syntax which explicitly declares Button belongs to Draw. This is the defining characteristic of nominal subtyping and in sharp contrast with what's called duck typing.

It's simply wrong to call nominal subtyping "duck typing;" it isn't a matter of "wording."

Perhaps you wanted to say "polymorphism"? (impl MyTrait for MyStruct achieves ad-hoc polymorphism.)

[carols10cents]

It's simply wrong to call nominal subtyping "duck typing;" it isn't a matter of "wording."

The current text does not say that Rust is a duck typing language, it draws a comparison to duck typing:

Only being concerned with the messages a value responds to, rather than the value's concrete type, is similar to a concept called duck typing in dynamically typed languages

[carols10cents]

The reason traits are like duck typing are that in both cases, you don't care about the actual type of the instance you have, you only care that it has the behavior you need.
Hmm, it does make sense in that way. Perhaps it makes sense to point out the ways in which it is similar and how it's different (safer)?

I'm not sure at what point we made this change, but to me we have text now that says this:

In the implementation of run on Screen in Listing 17-5, run doesn’t need to know what the concrete type of each component is. It doesn’t check to see if a component is an instance of a Button or a SelectBox, it just calls the draw method on the component.

There is another spot that I've added a "similar to". I still stand by this comparison, so I'm going to close this issue. Thank you all for your feedback!

[snawaz]

@carols10cents

Only being concerned with the messages a value responds to, rather than the value's concrete type, is similar to a concept called duck typing in dynamically typed languages

That is NOT similar to duck typing, as it requires you to implement a specific trait to work. That is similar to polymorphism as that requires you to implement a specific base to work. In duck typing, there is no such requirement. Its only requirement is that the function is callable on the object.

In Rust, it is more like compile-time polymorphism.

Also, duck typing could exist in statically typed languages too. C++ supports that.

[iCodeSometime]

In regards to this argument, I don't see much difference between traits in rust and interfaces in Java, C#, etc. So, now they all use duck typing because they have interfaces? lol

This is literally the opposite of duck typing imo