-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking issue for potential breaking changes #47
Comments
I don't get why #15 is considered breaking. |
Quoting #15:
I vaguely recall seeing some cases where type defaults don't fully prevent breaking changes, but I'm not sure off-hand. The result type is definitely a problem though, because associated type defaults are still unstable. |
IMO the |
Here's the breaking case I was thinking of: rust-lang/rust#69454 (comment) |
How about introducing to the conversion traits |
|
I was talking primarily about the |
Any thoughts on when is the right time to execute these breaking changes? It is nice the crate is so stable, but also would be great to get these changes and ship a 1.0. Thoughts? I'm willing to help make these changes! |
As per my comments in #197, I think we should also add |
My current opinion is that we should just bump to 1.0 as-is, reflecting the status quo of an effectively stable API. We would publish re-exports in 0.2.x for compatibility, just as the transition from 0.1 was managed (the "semver trick"). The changes in this list would all be for a potential 2.0, but I don't know if there's a right time to do that. I fear it will be really painful. It also doesn't help that I'm the only active maintainer here, and I don't have much time for it -- the refactors we all want would probably overwhelm me just to review... |
@cuviper Cutting a 1.0 release because you don't have enough time to work on the crate is not a great practice in my opinion, especially for a core crate. Maybe you could attract additional maintainers via announcement on URLO/Reddit/etc? |
It's a lot of work growing a community! Thank you so much for all your contributions thus far, so much of the Rust community (and now for-profit companies) depend on your work and it's going unappreciated. What support and help can we give to help ship a new release with breaking changes? Which parts of releasing fill you with the most dread? |
@frewsxcv I think even before we contemplate breaking changes, I need to get more maintainers on board -- not that I will be going away, but I shouldn't be doing this alone. And that's largely on me, that I haven't fostered anyone else into the project, but I don't think it's an easy thing regardless.
I don't think it's as simple as that, because there's a large degree of trust required, especially for a crate with such wide use. Frankly, I also don't have the time to mentor a bunch of eager new rustaceans as maintainers, as nice as that might be, since I'm not even keeping up with issues and pull requests right now. I know there's a tipping point where new maintainers reduce the rest of that load, but we have to get over that hump. But I recognize the need to break this gridlock. The two of you are both well-established maintainers in the Rust ecosystem -- would you be interested in joining @rust-num and helping out? Whether for just this crate or for the whole suite, let me know. I'll keep this door cracked if other experienced folks are interested too. PS: I fear that I may get flak about gatekeeping or similar, so I want to emphasize that contributions are welcome from anyone, regardless of experience. It's only maintainership that needs a higher bar, and new contributors will have a longer road of establishing their own track record. This twitter thread also captures some of that sentiment. |
I know I'm just a rando, but if I may make a suggestion, perhaps you could namespace breaking traits as a stopgap? It's less maintainership burden, doesn't involve the burden of supporting multiple releases, and solves the immediate problem. maybe like |
@Elizafox yes, but even better put them in a separate crate so they can be versioned separately. |
num-traits is somewhat of a de facto stable crate. Since these traits are often found in the public API of other crates, we really want to avoid the sort of ecosystem split that a breaking-change semver bump might cause.
Nevertheless, it's a good idea to track what breaking changes we might want to make someday, now found in the list below. Links are included to postponed issues, which often have more details. They will be closed in the meantime, but discussion can continue.
epsilon
implementation forFloat
Remove defaultepsilon
implementation forFloat
#4Num::FromStrRadixErr
should have Trait bound Num::FromStrRadixErr should have Trait bound #6Float
More features forFloat
#8num::traits::PrimInt
should take or returnusize
instead ofu32
All bit twiddling functions in num::traits::PrimInt should take or return usize instead of u32 #14std::num::Checked{Add,Sub,Mul,Div}
should have type parametersstd::num::Checked{Add,Sub,Mul,Div}
should have type parameters #15Mul
by reference inpow
UseMul
by reference inpow
#18Float
trait depend onFloatConst
. Make the Float trait depend on FloatConst. #20Default
,Display
, andDebug
trait bounds to PrimInt Add Default, Display, and Debug trait bounds to PrimInt #44Signed
andUnsigned
Easy conversions betweenSigned
andUnsigned
#46impl
forReal
trait prevents parameterized implementations. Blanketimpl
forReal
trait prevents parameterized implementations. #49FloatCore
byBounded
? Bound FloatCore by Bounded? #55Reverse
(rust 1.19+) impl Bounded for Reverse #65One::is_one
a required method and remove itsSelf: PartialEq
Add methodis_one
toOne
trait #5 (comment)LowerBounded
andUpperBounded
(Add LowerBounded/UpperBounded traits #210) should be super-traits ofBounded
The text was updated successfully, but these errors were encountered: