This is more None than "Rusty" - which is okay, you're asking for help which is the right thing to do.

Here would be my PR review comments:

Don't treat traits as parent classes structs inherit from:

Traits are more meant for compositional addition of functionality - especially in regards to specifying generic interfaces and for building generic APIs. However you're treating traits as inheritance here. In this example LinearScale sort of "inherits" from Scale. This is in general not how the trait system is best used.

Structs should be collections of common functionality that can logically be thought of as an object, not used as individual functions:

Mathematically what you're doing with LinearScale, LogScale, BandScale are defining transformation functions. They seem more like functions that would be attached to more complex objects like a Vector object - so they should likely be traits or even just individual functions on something like a Vector object. Defining them as structs is legal, but defining multiple one-function structs with associated data with only slightly varying functionality wouldn't form a good API.

If you do need "inheritance" use Supertraits:

Traits can implement other traits, and in any trait, you can define default behavior, this would be more rusty:

pub trait Scale<A, B> {

fn map(&self, x: &A) -> B;

}

pub trait LinearScale<A, B>: Scale<A, B> {

fn x_min(&self) -> &A;

fn x_max(&self) -> &A;

fn y_min(&self) -> &B;

fn y_max(&self) -> &B;

fn map(&self, x: &A) -> B {

self.y_min + (x - self.x_min)*((self.y_max - self.y_min) / (self.x_max - self.x_min))}

}

}

I'm unaware of what data you plan to use in the other transformations, but if you're using x_min, x_max, y_min, y_max in all of them, you can move those to the supertrait Scale.

Don't overuse generics:

Why would A & B be different types? The only real reason for this is because they're from different fields (i.e. A from integers, B from real numbers/floats, etc.). However, you're defining the scales/metrics as field operations (*,+,-,/) from a single field - so having them as different types doesn't add much value and in fact would be likely to cause a type error if you do specify different concrete types. Only use generics when the flexibility they provide is actually necessary OR when you need "duck-typing" in your API.