-
-
Notifications
You must be signed in to change notification settings - Fork 273
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
Split the time
crate
#350
Comments
The primary blocker of weak dependencies will land in Rust 1.60, reaching MSRV on 2022-10-07. At some point before then I'll investigate the |
Looking into the For what it's worth, I may still go ahead and just hack some raw HTML into the definitions to simulate the existing annotations. The improvement in code structure may make it worthwhile. |
The main
time
crate can be moved totime-core
, while the formatting and parsing mechanism (including parsing format descriptions) can be moved to thetime-formatting
crate. At that point, thetime
crate could re-export everything fromtime-core
,time-formatting
, andtime-macros
, behind feature gates as appropriate. Implementations of internal helper traits intime-macros
can be accomplished via a newtype.The primary advantage of doing this is that the
time-macros
crate will no longer have to duplicate logic for a sizable number of items. Thus this change in structure will be an overall reduction in code. I believe that it will also improve compile-times, although this is already decent. Certainly the largest advantage is that because of the deduplication the macros will always be in sync with the core crate. This ensures that something can't exist in one and not the other.These sub-crates, like
time-macros
, will not be intended for direct usage and should be considered an unstable implementation detail.The
time-formatting
crate is blocked on rust-lang/cargo#8832; interaction between features would be far from ideal until this is stabilized (for six months per MSRV guarantees). Another blocker that I don't believe there is an issue for — if it's even desired — is having#[doc(cfg(…))]
visible on re-exports. Without this a user may think that an API is available when it isn't. I'm guaranteeing that the feature flags intime
,time-core
, etc. all match but the compiler is unaware of this and thus removes the annotation in its entirety.The text was updated successfully, but these errors were encountered: