Update to Serde 1.0

[cuviper]

See #281, and this was previously in the next branch after #305.

• Update to Serde 1.0  num-bigint#9
• Update to Serde 1.0 num-complex#8
• Update to Serde 1.0  num-rational#9

[CAD97]

Now that rust-num/num-rational#9 is closed, do we have an estimated timeline for when we can expect to see a num v0.2.0 (pre)release with serde1 support?

At current, it is possible to monkey-patch together a num 0.2-git by adding a git dependency on the children of num, but it's not exactly pretty.

Scanning the num reexports, I spot the following issues marked with a 0.2 milestone:

• tagged [breaking change]
  • [num] Missing default-features = false for bigint dependency
  • [bigint] Hide bigint implementation details
  • [complex] Make std a feature, using #![no_std] otherwise
• not tagged [breaking change]
  • [bigint] Support the assignment operators for BigInt [help wanted]

[cuviper]

Thanks for the summary -- there's really not much left! I don't have a schedule, but I'll try to wrap this up soon. Looking at your list:

• num will need to clean up all its features to match the updated sub-crates.
• num-bigint details: I already made the error type opaque, just want to remove big_digit::* from the public API.
• num-complex no-std had a PR that stalled. I may just add the std feature with all functionality masked without it for now, then proper no-std support can come later.
• BigInt assign ops don't have to be done for 0.2.0 either, but it would be nice.

[cuviper]

num-complex no-std had a PR that stalled. I may just add the std feature with all functionality masked without it for now, then proper no-std support can come later.

Hmm, it's not that easy to defer, because some no-std features will need to switch to FloatCore, and we can't change that in the API later.

[CAD97]

Is there a reason Float doesn't have FloatCore as a "supertrait"? I realize that changing that would break semver-compatibility in num-traits, so is pretty much a non-option, but having that would allow relaxing Float bounds to FloatCore without breaking semver compatibility.

If you want to go the nuclear route for no_std future-proofing, in addition to config'ing everything out when opting out of the std feature, you could double every bound from Float to Float + FloatCore -- that way, removing one of the bounds would strictly be semver-compatible (though may break inference because inference is tricky).

In any case, I can help out some next week. The easy step is just to get the repository in 0.2.0-git mode, and that way those willing to use git dependencies at least don't have to recreate the facade to use the 0.2 previews.

[cuviper]

Is there a reason Float doesn't have FloatCore as a "supertrait"? I realize that changing that would break semver-compatibility in num-traits, so is pretty much a non-option,

That's exactly the reason this wasn't done.

The easy step is just to get the repository in 0.2.0-git mode,

You mean for num itself, pointing to the existing 0.2.0-git of sub-crates? I actually did start that on my own branch here: https://github.com/cuviper/num/tree/release-0.2.0

[BelfordZ]

Any ETA on this? Trying to plan out some feature development around this.

[cuviper]

Just need to finish release notes in #367, hopefully in the next day or so. If you want to kick the tires on that, it would be greatly appreciated!

[BelfordZ]

Thank you greatly @cuviper :) :)