3 ms·
> But which one of those? The situation is far simpler than that sentence implies; a + b is (always) equivalent to Add::add(a, b). The same trait/impl rules a
by dbaupp 8y ago
> But which one of those?
The situation is far simpler than that sentence implies; a + b is (always) equivalent to Add::add(a, b). The same trait/impl rules apply to + as to normal trait function calls.
> Are there implicit type conversions?
No, as people quickly encounter if they do numeric/matrix computation in Rust, all type conversions are explicit.
> The good news is that the Rust programming book is finally coming out in just 6 more days. So there's something better to read than this.
Even better news: that particular Rust book has been available online for a long time, as the official documentation.
- steveklabnik 8y agoTiny, tiny addendum here: > a + b is (always) equivalent to Add::add(a, b) method call synatx does auto ref/deref, so it may be Add::add(&mut a, b) or Add::add(&a, b) too, etc.
- chrismorgan 8y agoMethod call syntax does, but operators don’t.
- steveklabnik 8y agoAh ha, I didn't realize that. I thought it desugared to the method call, which then gets de-sugared to the fully qualified syntax. That does seem more complicated than skipping the intermediate step, and since we have so many implementations for the various ref or not'd version, it ends up feeling the same. Thanks!
- dbaupp 8y agoYep! That's why it's equivalent to Add::add(a, b), not a.add(b). (This was definitely something I had to check, though, and, as you say, a tiny detail that's almost certainly irrelevant to most code that people write.)
- steveklabnik 8y agoSee my response to Chris, I actually thought it was! My bad!
- chrismorgan 8y agoAh, the old days when operators worked by reference… it was much harder to express precisely what the + sugar was back then.