Skip to content
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

Move Duration type to libcore #46520

Closed
clarfonthey opened this issue Dec 5, 2017 · 4 comments
Closed

Move Duration type to libcore #46520

clarfonthey opened this issue Dec 5, 2017 · 4 comments
Labels
C-feature-accepted Category: A feature request that has been accepted pending implementation. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@clarfonthey
Copy link
Contributor

Right now there isn't anything that requires keeping this type in libstd, and it may be useful for libraries that work with time in a no_std context. It makes sense to move this type to libcore.

@kennytm kennytm added C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Dec 5, 2017
@bstrie
Copy link
Contributor

bstrie commented Dec 5, 2017

I thought that all types in libstd were there for a reason, is there a historical reason that this was left in? Should we audit libstd for other types that don't need to be there?

@clarfonthey
Copy link
Contributor Author

@bstrie everything in libcore is also in libstd, more or less. libcore is just a smaller version of libstd that doesn't rely on platform-specific behaviour at all.

I do think that libstd should be audited for types that can be moved to libcore; this is just one case of that.

@sfackler
Copy link
Member

sfackler commented Dec 5, 2017

AFAIK it's only in std because the rest of the time module was defined there, and Instant and SystemTime both need std. Seems fine to move Duration though.

@Mark-Simulacrum
Copy link
Member

I think a PR for this would be reasonable. Marking as feature-accepted.

@Mark-Simulacrum Mark-Simulacrum added C-feature-accepted Category: A feature request that has been accepted pending implementation. and removed C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Dec 6, 2017
bors added a commit that referenced this issue Jan 31, 2018
Move Duration to libcore

Fixes #46520; should be merged after #46508.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-accepted Category: A feature request that has been accepted pending implementation. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants