Rust book 2018 `impl Trait`part need fix


When the glorious impl Trait feature shipped, a few objections to it arises because of misunderstand of it.

A review to the current sections in the 2018 editon of the book shows even the book itself have misunderstanding on this feature. One major issue is that the text seem to imply the following

pub fn notify(item1: impl Summary, item2: impl Summary) {

pub fn notify<T: Summary>(item1: T, item2: T) {

are equivlent. Of cause they are not: the later requires item1 and item2 have the same type and the former does not.

For this reason, I reviewed the chapter 10-2 and make my changes here

Please give me feedbacks and correct me before I make a pull request to the book.

Thank you.


A pull request was created.

Please spread the word:

impl Trait is anonymous types in function signature

impl Trait is anonymous types in function signature

impl Trait is anonymous types in function signature

Because, you know, too many people think that impl Trait is inconsistant in parameter position and return position. But it is actually perfectally consistant with the above understanding!


In parameter position it is “Universal” in return position it is “Existential”. So not exactly the same. What does this mean? It means that in parameter position ANY (universal) thing that implements the trait is acceptable to pass as the parameter value and the function will correctly monomorphize/specialize for the particular type passed. On the other hand, in return position it declares that SOME (exists) type will be returned that implements the given trait. It will always be the same type, but, you won’t know what it is (as the caller), you’ll just know you are getting back some type, that exists, that implements the given trait.

EDIT: Ignore this, I realize now your point was something else after having read the PR more.


I am not arguing that in parameter position is “universal” and in return position it is not. I am saying that anonymous type is the axiom, and universal and existential is corollary of this fact. So if there are any “inconsistency”, it is because the parameter is NOT the return position. That is all.

This is similar to, a function should be contravariant in the parameter position, and covariant in the return position. But this does not mean any inconsistency.