-
Notifications
You must be signed in to change notification settings - Fork 517
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
Ergonomic replacements for panicking APIs. #1491
Comments
@turalcar Sorry for all the deprecations. I understand they cause churn and make chrono less nice to use! The plan is to move chrono away from a panic-by-default design to better match current rust standards. Maybe the macro's I proposed in #1270 can be a help to you? I certainly look forward to them a lot for the same reason. Also most methods are now const. Maybe that allows you to move some of the fallibility to compile-time? |
Moving away from panicking APIs is fine, but there should be more time between introducing new APIs and deprecating old. |
May I ask what your thoughts are WRT having a minimum chrono dependency version? Are you 'reluctant to impose this' because of the deprecation warnings? And what would you consider a reasonable time? |
My thinking is that some of our users may not be so fast to update their dependencies. If they stay on older chrono versions, and we require a new one, then they have to either
Scenario 2 is good - more apps using more recent versions of library, yay. Other scenarios not so much :< Regarding the reasonable time - I'm not sure, I didn't think about it. I just felt that in this case it was a bit too short - deprecation of old APIs a little bit over a month after introduction of new APIs, and after 2 minor releases (from what I see: 25 January, 0.4.33 - introduction, today, 0.4.35 - deprecation). |
Thank you for the thoughtful comment. Let me link #1408. |
This looks perfect. I suppose macros for
Any compiler worth its salt would replace the whole |
I don't see how this could happen. Within a semver-compatible version range, only one copy of a library can be used. So if your downstream users adopt a new version of your crate and that crate requires a newer version of chrono, downstream users will automatically also get the same newer version of chrono. Do you have a concrete example of any issues like this that have come up? |
What is the currently recommended way of initializing a const Duration? Panicking APIs have been deprecated, but unwrap isn't const yet. |
I'm also missing a const alternative to unwrap. In chrono we are internally using an Edit: macro_rules! unwrap {
($e:expr) => {
match $e {
Some(v) => v,
None => panic!(),
}
};
} |
Yeah, I've never called any of these methods based on anything that WASN'T a constant value. Now I get to go in and add a lot of unwrap calls for the sake of ergonomics. Talk about annoying. |
Published chrono 0.4.36 which undoes the deprecations on |
The issue there is that the dependant crate may be using |
Pinning dependency versions in (low-level) libraries is almost always a bad solution that people shouldn't do -- you didn't really answer the question for concrete examples, though? |
Crate
No library pinned a dependency version but a semver compatible update of one library caused a lot of deprecation warnings for another one.
That's the issue the comment was getting at exactly, the users are forced to update For the record, I'm not saying there shouldn't be deprecations or that every deprecation should be handled with a major version update, I'm just trying to explain the scenario since you said you don't see how this could happen. |
I'm going to close this issue. I think the changes have been a net good for panic safety which is important for robustness even though I don't dispute there has been a cost in ergonomics -- but, I think prioritizing robustness over (some amount of) ergonomics is generally the accepted approach in the Rust ecosystem. That said, if people want to argue for concrete improvements that don't have some of the downsides of the older API I'd happy to see issues/PRs about that. (For example, go upvote or give feedback on #1270.) |
When a lot of panicking APIs, such as
NaiveDate::from_ymd()
were deprecated I thought it to be a momentary aberration and locked the version at 0.4.22. A year has passed and proven me wrong.I replaced
.pred().pred()
with- Duration::days(2)
and now that's deprecated too.In all of my code
from_ymd()
,from_hms()
etc were only used ever with literals. I don't think that's uncommon. One could try to enforce that with a macro (e. g.date!(2024, 3, 6)
similarly to howprint!("Hi")
only accepts string literals).Whatever a good replacement is, it should've been implemented before the old version was deprecated.
The text was updated successfully, but these errors were encountered: