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
Breaking change wish-list #650
Comments
Separate feature flags for |
@jeff-hiner I'll be honest, it's not likely to happen. The clippy issue you linked would solve your request while being more general purpose and would avoid the overhead of an additional feature flag. I'm also not aware of any widely-used crates that gate |
The To me the situation here is similar to |
Note that I was responding to the use of separate feature flags for
|
Oh with the human-readable serializer you mean? That's fair. |
Looks like the clippy issue has been parked for 2 years. It was claimed, but I don't see any progress over the last year. I'd try to PR in a fix myself but as it involves digging into clippy's parser I honestly have no idea where to even start. Not optimistic that's going to be fixed soon. I'm guessing here, but it looks like the current default is intended for human-readable serialization like I don't mind having to explicitly annotate Since there's no one "right" way to |
Are we looking at the same thing? There was an update just a couple days ago on a PR that implements it. It may have stalled, but it is at least on the person's backlog.
The default is intended to be something human-readable (when that flag is enabled) that can also be deserialized. There was no reasoning beyond that.
A trivial check shows that
That's an awfully large leap. As I said, the intent was to have something that is human-readable and can be round-tripped. Just as with formatting being present because |
I'm looking at rust-lang/rust-clippy#8581 as linked in my original comment. That issue was opened 24 Mar 2022 (over two years ago), then claimed in June of the same year. A separate author opened a PR that was last touched at the beginning of the year, in Jan 2024. That PR received feedback in Feb, but no commits have been made since. As of right now the PR has conflicts. It appears the work required to have clippy support the appropriate parsing is non-trivial, or at the very least the PR implementation is controversial.
A trivial check on docs.rs shows that chrono does in fact use RFC3339 for |
Things aren't fast in Rust given that it's entirely driven by volunteers. The PR author commented just this week that they intend to continue work on it. Given that you presumably are using this as part of your employment, that is why I suggested asking for some time to work on the issue.
It definitely isn't correct for the reason that I stated. It's not RFC3339 if it doesn't strictly follow the specification. |
Note: There is no breaking change current planned. This issue is to keep track of things that may happen when there is a breaking change at some undetermined point in the future. Items are in no particular order.
Potential changes
These are mostly things that I have thought about at some point, with varying levels of certainty.
large-dates
feature flag. Support the ±999,999 range of years unconditionally, adding a modifier to the[year]
component to solve the issue of ambiguity.serde-well-known
feature flag, which is already deprecated in favor of using the relevant flags (serde
,formatting
, and/orparsing
) directly.FormatItem
opaque and requireFormatItem::Literal
to be valid UTF-8. Likewise forOwnedFormatItem
.Copy
implementation forParsed
.Duration
toSignedDuration
or something else.Duration::seconds
generic overi64
,f32
, andf64
. Similarly forsaturaturating_seconds_*
andchecked_seconds_*
. Alternatively, have aseconds_float
method that is generic while keeping the integer case separate.Duration::time_fn
. This is a carry-over fromtime
0.1 and was presumably meant as a poor man's benchmarking tool.Instant
is not meant to be used in that manner.time::Instant
in favor of an extension trait onstd::time::Instant
. This would reduce the number of trait implementations needed. The extension trait was added in v0.3.35, withtime::Instant
being deprecated at the same time.The text was updated successfully, but these errors were encountered: