[fontdrasil] Typed coordinate spaces

[cmyr]

This started out as just an experiment, but I ended up fleshing it out to the point where it is mergeable, if we wish.

The basic idea is that instead of having separate types for each coordinate in each space, we actually use the space as a type parameter, and then have a single Coord type that is generic over that parameter. This means that we define all conversions in terms of the coordinate space, and then we can define methods on a single Coord type that are available everywhere. (We can also define methods that are specific to a coordinate in a particular space.)

So... I'm anticipating a lot of tell-me-whys here, and I fundamentally agree that this is not a hugely important change. The main advantages as I see them is that this version has slightly better ergonomics and is a bit more maintainable, while generating slightly less code. The downside is that it uses an advanced language feature, PhantomData.

Finally, if we decide this is not actually an improvement then I hope at least it is a useful illustration of an idiomatic approach to this problem.

edit:

Having played with this a bit more, I am more convinced this (or something in this vein) is the right design. The basic rationale is that doing things this way lets you make other code more generic; for instance it would now be very easy to make our PiecewiseLinearMap be generic over a pair of coordinate spaces, like:

struct PiecewiseLinearMap<FromSpace, ToSpace> {
    from: Vec<Coord<FromSpace>>,
    to: Vec<Coord<ToSpace>>,
}

and because we know that both types are Coords, we can know there is always some available set of methods. This would not work if we were using the current coord types and doing PiecewiseLinearMap<T, U> since we don't now anything about T and U in that case.

basically: The advantage of Coord is that it encapsulates all of the general behaviour of a coordinate, regardless of the coordinate space, and that is actually a useful distinction in some cases.

[rsheeter]

At a glance I like it, will do an actual review later.

[cmyr]

I've added a second commit here that impls PartialEq<f32> for the Coord type, which lets us write much simpler tests (but you still cannot compare a coord to another coord in a different space, so this doesn't undermine our typing)

[anthrotype]

leave it like this, sometimes it is useful to be able to make a NormalizedCoord that exceeds -1 or +1 (but is still within the F2Dot14 bounds) e.g. restricting axis min/max duing VF partial instancing.
It's clear already what needs to be done when the NormalizedCoord is used; 0 is default by definition, -1 is min, +1 is max, anything beyond will never be accessed because instance input location must be clamped.

[anthrotype]

looks neat though I am still unsure what the PhantomData is actually doing

[anthrotype]

Oh I see. The generic struct Coord doesn't store a Space type but needs to behave differently based on it; so the zero-sized PhantomData here acts as a "type marker".
Still not clear why it isn't just PhantomData<Space>, I see you added a comment with a link, but i'm scared of the rustonomicon

[cmyr]

So yea, PhantomData is a way of making a type behave as if it contains some type or lifetime without actually containing that type or lifetime, which is useful for things like this.

The reason you don't do PhantomData<T> (at least in this case) is that for that type the compiler behaves as if you actually contain the given type. In particular it means that the compiler will assume that the type may drop a value of T when it goes out of scope, which we don't want. We also want to make sure that coords can always be passed between threads, so I just looked at the chart in the nomincon and picked the type that offered covariance + send + sync. 🤷

[rsheeter]

I wish there wasn't a macro but I don't have a better idea.

[cmyr]

The alternative is just to write essentially the same code three times. Is your concern based on the insanity of macros in C? Rust's macros are much more constrained, and it makes it easier to refactor things in the future, since we'd only need to edit in one place.