Open Patiga opened 1 year ago
I think this time a PR would be appropriate (that would also allow you to test before changes are published).
Some guidelines:
fixed
; the solution should work for any "number type" crate (as long as that crate implements traits from ubiquitous crates such as num_traits
, but for that purpose I'd say az
may count as well)fixed
(which I hope we don't), then this should be gated under a non-default feature.The point is, I'd like to avoid a situation where vek
"blesses" a few specific crates that are not widely used, adding to its dependencies; there's a threshold where it might be more elegant to have a separate crate (such as "vek-fixed-interop", I'm exagerrating but that's the idea)
Methods can be added as long as they are general enough (so stuff based on FromPrimitive
/ToPrimitive
).
The az
crate looks ok as a "common ground" that number types can implement, but I'm hesitating because it looks, although well-designed, quite specific and niche.
In your specific project, you might find it more convenient to have "extension traits" implemented for all vector types, where you add conversion methods as you see fit (then put the trait impl into a macro re-used for all vector types).
The map()
method can make this easy; there should be no need to get as "sophisticated" as the current macros in vek
's internals.
If I understood correctly it's just a matter of using To/FromPrimitive
to cast to f32/f64
and that's it? Then helper methods could be added to vectors as you suggest, but I'd like to avoid getting further than that.
Would you consider adding az
as an optional dependency, or would you rather avoid that as well?
I do understand that optional dependencies can also kind of bloat, so I wouldn't mind if you aren't a fan of that
I think I'm OK with az
as an optional dependency.
Context: I'm using
vek
in combination withfixed
point numbers. In case you are curious, the project I'm working on istwmap
(and the few other things I build on top of it).Vec2
currently hasnumcast
as its main method of conversion afaik.numcast
relies onNumcast
, whichfixed
doesn't implement (reasoning).Conversion methods which I think could be added
ToPrimitive
andFromPrimitive
(I guess alsoAsPrimitive
if you want to be thorough)From
,Into
,TryFrom
andTryInto
based conversion. I personally don't need them yet, but I can see me needing them in the future. Implementing the trait is not possible, but methods using the traits could help.az
crate has a nice set of conversion traits. These are not implemented generically and thus can be implemented.fixed
supports them, but otherwiseaz
doesn't have that many downloads.Like last time, I'm willing to put my own time into this, but I won't stop you if you judge that it's worth your time :) I'll continue opening issues for non-trivial things, as you suggest in the README