Many structs in vecmath will have multiple function definitions depending on the other type in the operation. For example, Normal3f has dot(&self, n: &Self) and dot_vector(&self, v: &Vector3f).
It would be better to implement one dot() function, with a generic T constrained so that only Normal3f and Vector3f satisfy it; perhaps some Normal3fDottable trait that both Normal3f and Vector3f implement, that might just be a supertrait of some other traits.
This simplifies the interface of the structs in vecmath so that callers don't need to remember which dot() to call based on what they want to dot with the normal.
This is how we can accomplish "overloading" these functions despite Rust not having overloading; added benefit is that users of the vecmath lib could implement a type that can dot() with Normal3f if they really wanted to, for example.
Many structs in vecmath will have multiple function definitions depending on the other type in the operation. For example, Normal3f has dot(&self, n: &Self) and dot_vector(&self, v: &Vector3f).
It would be better to implement one dot() function, with a generic T constrained so that only Normal3f and Vector3f satisfy it; perhaps some Normal3fDottable trait that both Normal3f and Vector3f implement, that might just be a supertrait of some other traits.
This simplifies the interface of the structs in vecmath so that callers don't need to remember which dot() to call based on what they want to dot with the normal.
This is how we can accomplish "overloading" these functions despite Rust not having overloading; added benefit is that users of the vecmath lib could implement a type that can dot() with Normal3f if they really wanted to, for example.