I quite like this; it's quite ergonomic. Is there any downside to users who don't want T=f64? Or does the API remain exactly the same as before for the general case? May be we could move some of the tests to f32 to explain the usage with a non-default type.

Or does the API remain exactly the same as before for the general case? May be we could move some of the tests to f32 to explain the usage with a non-default type.

The API remains exactly the same as before for the general case.

I've added some docs (and a doc test) to the geo-types/lib.rs - WDYT?

Overall I think I'm in favor. One very small concern I have is this may encourage library authors to write something like:

struct Shapefile {
    fn from_geo(geom: geo::Geometry) -> Self {
         ...
    }
}

When they should really be writing geo::Geometry<T> so more types can be supported

they should really be writing geo::Geometry so more types can be supported

I agree - that is a potential downside. One of the reason's I think it's not so bad though, is that, if there's demand for it, those trait implementors could later upgrade to add generic support in a non-breaking way:

- struct Shapefile {   
-   fn from_geo(geom: geo::Geometry) -> Self {
+ struct Shapefile<T: CoordNum = f64> {
+   fn from_geo(geom: geo::Geometry<T>) -> Self<T> {
          ...
    }
  }

Could this possibly be considered a breaking change for geo-types? I don't think it would be but I can't help but wonder if there's some edge case we're not considering 🤔

This is intended to be non-breaking, and I believe it to be. But it's always possible that I've missing something.

Anybody else care to weigh in?

I've gotten somewhere between one and two positive responses, and (I think) no unaddressed concerns.

Otherwise I'll plan to merge in a couple days.

I like it too, and the doc additions make clear what's happening so I'm not too worried about confusing errors.

bors r=rmanoka

Build succeeded:

• ci result