Michael Kirk

> Found the reference! https://rust-lang.github.io/api-guidelines/necessities.html#c-stable My read of this is we don't need to worry about `log`, since it's not a **public** dependency. > Imaging that log adds a rust-version...

> So I think geo-types is the only relevant dependency in terms of 1.0. Having thought about this more, geo-types 1.0 is __relevant__, but not necessarily blocking us from releasing...

Can you point me to a crate that recommends missing features? Sounds interesting.On Mar 16, 2024, at 09:11, Nick Kocharhook ***@***.***> wrote: Ah, this works if you install the required...

Oh that's nice. Looking at that example, it's within the context of a procedural macro, so I don't think we can use that technique. I wonder if it's possible outside...

Sure @amir002001. Please rename the methods in GeodesicArea to match the names used in the other two traits. Leave the old methods with the existing spellings for a while, but...

That seems useful. With &str as input, it's straight forward. With an arbitrary `impl Read` as input, it's less straight forward, since reading ahead to infer the type will consume...

I think that sounds really promising. I’d prefer not to lose support for integer geometries though. I wonder if there’s a way to accommodate both?

I don't think we can solve it as phrased. But maybe we could achieve what we want (fast float WKT while still allowing integer WKT) doing something like we did...

Right - I think that's a fair trade. I have yet to encounter someone actually using any of our geo libraries for an exotic numeric type, but I'd be interested...

To be clear, I'm suggesting we could break things for exotic numeric types and wait to see if anybody cares before we put a bunch of effort into supporting it.