search

fu5ha / ultraviolet

A wide linear algebra crate for games and graphics.
https://crates.io/crates/ultraviolet
750 stars 81 forks source link

Comparison traits for wide types not accessible on API #132

Open dooost opened 3 years ago

dooost commented 3 years ago

Currently the comparison traits CmpEq, CmpGt, CmpGe, CmpNe, CmpLt, CmpLe are not exported from the crate, which makes dealing with wide types inconvenient.

It's possible to add wide as a separate dependency and import the comparison traits, which is far from ideal. Considering the wide float types are re-exported from ultraviolet and are rather crucial to effectively using uv's own wide types, I think these traits should also be re-exported on ultraviolet's API.

Use of cmp_gt is also mentioned in the Ray-Sphere Intersection example on README.

dooost commented 3 years ago

If you don't see any concerns with this, I'd be more than happy to open a PR :)

fu5ha commented 3 years ago

Yeah these should probably be re-exported. Maybe in a prelude module or something, PR welcome :)

dooost commented 3 years ago

I had some time to have a look at this, and I'm having a bit of a hard time settling on a suitable module for these traits. Sorry in advance for the long-ish post, I'm fairly new to Rust and not super familiar yet with project structure common practices. :) I think prelude kinda implies that use ultraviolet::prelude::* should give you a list of types and traits that would be used in majority of projects that use ultraviolet, but I'm not sure that's the case with these traits or f32x4/8. I would expect prelude to contain some vector and matrix types as well and generally the types you use most when using ultraviolet, but I think ultimately this would be a bigger and more complicated question, how should such a list can be curated so that wouldn't result in too many redundant imports when using use ultraviolet::prelude::*. I considered a comparison module which felt a bit awkward as I'm not sure if there's anything else that could go there besides these traits. Another idea was to create a wide module that would re-export f32x4/8 and also the comparison traits, but it might be misleading if the wide module do not contain the wide vector/matrix types. But I can see scenarios in which such a module would be useful, if it does include the wide vec/mat types too - however that would be a bigger re-structure and I'm not sure if that makes sense with the bigger picture of your plans for this crate. Besides these, the simplest way of course would be to re-export these publicly from the crate root. (curently they're re-exported but with pub(crate)). While maybe not the most elegant solution, I can't really think of any downsides to this.

I'm wondering, what would you think would be the best course of action here?