This is what I’ve found:
In C and C++, two different operators are used for calling methods: you use . if you’re calling a method on the object directly and -> if you’re calling the method on a pointer to the object and need to dereference the pointer first. In other words, if object is a pointer, object->something() is similar to (*object).something().
What about Rust?
Rust doesn’t have an equivalent to the -> operator. Instead, Rust has what is called automatic referencing and dereferencing.
In other words, the following are the same:
p1.distance(&p2); (&p1).distance(&p2); Note: this automatic referencing behavior works because methods have a clear receiver-the type of self. Given the receiver and name of a method, Rust can figure out definitively whether the method is reading (&self), mutating (&mut self), or consuming (self).
I am not sureI understood the note correctly, what does it mean that there is a clear receiver? Also, doesn’t Rust actually have an operator for dereferencing (*) as well？
It’s because Rust is a significantly higher level language than C (and C++ gets held back by it’s C roots). In C there’s no such thing as a method, there’s only pointers. The closest you get to a method is a function pointer. C++ expanded on that with the concepts of class, object, and method, but stopped half way leaving an object and a pointer to an object as distinctly different concepts that are treated differently by the language. In order to do anything with a pointer besides change its address in C++ it must be dereferenced. The
->operator in C++ is really syntactic sugar for a dereference followed by a method invocation. In other words these are equivalentfoo->bar()and(*foo).bar()as stated in the quote you provided. C and C++ treat pointers as their fundamental abstraction and treat everything as special cases of pointers.Rust in contrast treats Objects as first class abstractions. It doesn’t really matter whether you’re dealing with the owned object or a reference to that object owned by a different scope, in either case the compiler knows at compile time what its type is and what traits it implements. Given that knowledge whether the method is invoked from the owned instance or a reference it’s treated exactly the same. Further because pointers as opposed to references are treated as second class citizens (relegated to the “here be dragons” of unsafe), the concerns of C/C++ about distinguishing between a pointer assignment and a pointer dereference aren’t particularly important. In general the times you need to explicitly dereference something are far more uncommon in Rust, with the compiler generally being able to work out on its own when it needs to dereference something or not.
The bit about the receiver just means that the compiler at compile time knows the actual concrete type of all references with the exception of dyn references which force compile time dynamic dispatch (in which case the compiler inserts and utilizes a vtable exactly like C++ does).