Support for numeric casts through `az` crate

[haibane-tenshi]

Support for numeric casts through `az` crate

[haibane-tenshi]

Yeah, understandable.

Actually, I was in a little bit of trouble when posting this: at the time there is no way to use any casting functionality (even integer to fixed of vice versa) and it required something like 10+ different casting functions to cover all types in my case. Such setup felt very cumbersome and annoying. But then after glancing through itertools docs another time I suddenly realized: you can use traits not only to generalize/abstract over APIs, but also to extend it. I guess I'll count it as learning experience :)

Now with this in mind, I would say it makes most sense to create an interoperability crate for the two which will provide traits with conversion functions instead of pushing change into euclid itself.

Anyways I'm closing the issue.

[nical]

I'm a bit reticent to adding a dependency to euclid because a lot of euclid's users are pretty vocal about having as few dependencies as possible. The other reason is that euclid breaking changes cause a lot of downstream crates to have to update and publish a breaking release as well which we try to avoid as much as possible.

az looks small, is no_std and hasn't changed in a while so depending on it is not out of the question if the motivation is really strong. Since it is only for the casting methods and we haven't heard from other users of euclid with fixed, I would prefer to let users make helper functions outside euclid for casts with numbers that aren't covered by NumTraits.