feat: ToPrimitive split into ToFloatPrimitive and ToIntegerPrimitive about num-traits HOT 7 CLOSED

I have no plans to start making breaking changes. For now, I think if you have such restricted needs, it might be better to just fork into a new crate for your environment.

from num-traits.

Features are meant to be additive. If crate A uses num-traits with some current features and uses floats, and crate B turns on the no-float feature, and then both are used as dependencies in some larger project, then A will be broken by B's choice. That's not acceptable.

Forking is not good option as will need fork whole crate tree built on top.

API changes also require the whole tree to adapt, and this crate has thousands of dependents.

You may be able to [patch] in a replacement crate, but overall I'd say that your specialized/restricted needs call for specialized crates.

from num-traits.

I would be happy to PR it solution has chances to be accepted

from num-traits.

Other option is to gate all float methods behind float feature

from num-traits.

Thanks for response.

Forking is not good option as will need fork whole crate tree built on top.

Smallest breaking change can be made by making disable of floats only if no default no-floats features is defined.
So if default features are defined on some already existing, all will be as before.

Only issue would be if all-features are used. So I doubt I saw it wide usage.

from num-traits.

Features are meant to be additive. If crate A uses num-traits with some current features and uses floats, and crate B turns on the no-float feature, and then both are used as dependencies in some larger project, then A will be broken by B's choice. That's not acceptable.

It looks very desired behavior. If somebody enables "disabling" feature, it will break all float usage in other crates, compilation will fail, which is right. Nobody to use floats.

API changes also require the whole tree to adapt, and this crate has thousands of dependents.

that is clear, anyway just tried to propose :) so need to adapt on forks or via gate(both likely).

You may be able to [patch] in a replacement crate

Patch will patch crate for all deps, so if any dep will impl float methods, they will fail to compile. So will need to patch all other crates built on top. Num based crates about fractions(ratio) and big integers(bigger than 128) are of interest.

but overall I'd say that your specialized/restricted needs call for specialized crates.

Thank you for response. I understand.

So my understanding (and usage), there are core::ops traits to be used in any context/need/vm. I just peek traits what work for me. num-traits has a lot of good traits generic enough and I use them a lot (Zero/One/ops).

But To/FromPrimitive are not generic enough, I cannot use to integer vs float primitives. Floats leaks to compilation result as part of format/display/debug routines, which breaks specialized environments.

I can use core::ops without touching float code, but I cannot do that with num-trait, which would be possible num-traits would be generic enough to be used in any context (so basically this states that breaking thousands of dependents is right thing to do to make num-trait as generic as core::ops). And after that num-rational and num-big and many other crates conforming from num-traits will work out of box for some(my) use cases.

from num-traits.

Another possible breaking change tbh can be done accopanying any breaking change

https://docs.rs/num/latest/num/traits/trait.Zero.html

Zero forces to have Add which limits Zero usage. I can have Zero without ability to add.
One is also useful without ability to Mul.

Also some part of num-traits is already splits float to float mod, so To/From primitive looks like just tech dept to split.

Closing for now so. Can send PR with gate or split of traits if any will be considered as option. In general I feel that not my specialized needs are kind of things, but that num-traits are not general enough(easy to fix, so breaking change) in the end.

from num-traits.