Rust Traits Deep Dive, Part 2

The Add trait is defined in `std::ops::Add` as:

    pub trait Add<RHS = Self> {
        type Output;
        fn add(self, rhs: RHS) -> Self::Output;
    }

Both the type of the `self` parameter and the concrete type of `RHS` determines which trait impl matches. For example: `2 + 2` chooses the `impl Add<i32> for i32 { type Output = i32; ... }` implementation (literal integers are of type `i32`). Something like `2 + &2` would choose `impl<'a> Add<&'a i32> for i32`.

> There's nothing here about what Rust does about conversions, but that may be covered in one of the other many parts of this series.

With operators, there are no implicit conversions involved, AFAIK. So all Rust can do is try and infer the type you want. For literal numbers, it can do so in a limited fashion. As seen above, if you write `let x = 42;` the type is inferred as `i32`. If you write `foo(666)` with `fn foo(x: u64)`, the literal 666 is inferred to be meant as `666u64`.

> 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.

You can already read it here: https://doc.rust-lang.org/book/second-edition/index.html :)

For what it's worth, I think python's case is fairly simple and easy to remember.

Python objects can define two different methods for operator * : __mul__(self, b) and __rmul__(self, b). When you see A * B, try A.__mul__(B) if A has a __mul__. If the call throws NotImplemented (usually due to B's type) of if A did not hava a __mul__ call B.__rmul__().

I think that's actually much simpler that relying on types for dispatch since operators tend to be more "flexible" in their operand types than normal functions.

Only implicit refs and derefs I think.

> It's a classic problem in language design. If there are no implicit conversions, users complain about having to write "1.0" instead of "1", or worse, having to write "1.0L".

Rust handles that by type-inferring literals, the literal itself does not impose a type.

If there are no constraints at all I think it defaults to i32. The type can also be provided explicitly as part of the literal e.g. 1f32 or 7u8.

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.

• `a + b`

• `a.add(b)` (provided std::ops::Add is imported and the type of a doesn’t have an intrinsic method named add, which would take precedence)

• `Add::add(a, b)` (provided std::ops::Add is imported)

• `<A as ::std::ops::Add<B>>::add(a, b)`, where A and B are the types of a and b (provided we’re not no_std).

(Note that `a.add(b)` would work if a is of type A and &A implements Add but A doesn’t, because of autoref/autoderef in method calls, while the other three approaches would not work, and would instead want you to write &a.)

Demonstration of most of this: https://play.rust-lang.org/?gist=c70a8c62fa0f304b1a8dceddf98...

In Go, there are special types for integer and float literals. Literals can be implicitly casted into any numeric type large enough to store them, but casts from numeric types into other numeric types must be explicit. So for example:

  funcThatTakesInt32(1) // works
  funcThatTakesUint64(1) // works too

  var x int32 = 1
  funcThatTakesUint64(x) // error: type mismatch
  funcThatTakesUint64(uint64(x)) // works: explicit cast

  x := 42
  y := 23.0

  for x := 0; x < 10; x++ {
    fmt.Println(someArray[x]) //subscript requires `int` index
  }

https://newrustacean.com/show_notes/e023/struct.script

but not

https://newrustacean.com/show_notes/e000/struct.script

This is a web site of presentations/lessons which has been generated from source code by a documentation generator, with each Rust module representing a topic. It's "cute", but really friendly to humans.

There is another way out of this, which is using different operators. Modern Unicode can help greatly with this, but even before that was common, Perl was doing something similar between some of its major types (numbers and strings). Since Perl types are dynamic, and may be used as a string or a number, there would be a lot of ambiguity on comparing two variables for equivalence if the comparison depended on the type. To solve this, Perl has two sets of operators, one for dealing strings (eq,ne,gt,lt,gte,lte, '.' for concatenation), and one for dealing with numbers (==,!=,<,>,<=,>=, + for addition). What these primarily do is interpret both sides as the desired type before the comparison. This greatly reduces ambiguity, but does require more operators be internalized before language proficiency is achieved.

This is of course much harder to accomplish and becomes much more complicated as you increase the number of types. That said, it's an important concept and could help quite a bit in circumstances where things can be ambiguous (for example, your Python example).