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

Panic on overflow in Duration::new constructor #33072

Merged
merged 1 commit into from
May 6, 2016

Conversation

tbu-
Copy link
Contributor

@tbu- tbu- commented Apr 18, 2016

Panicking on overflow is also done for +, and it replaces the
currently incorrect overflow behavior of wrapping around, which does not
make sense for Durations.

@rust-highfive
Copy link
Collaborator

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

Panicking on overflow is also done for `+`, and it replaces the
currently incorrect overflow behavior of wrapping around, which does not
make sense for `Duration`s.
@GuillaumeGomez
Copy link
Member

GuillaumeGomez commented Apr 18, 2016

Instead of panicking, wouldn't it be better to return a Result<Duration> (or an Option)?

@bluss
Copy link
Member

bluss commented Apr 18, 2016

Shouldn't it just use the regular debug assertions for overflow? Those should work fine here?

@tbu-
Copy link
Contributor Author

tbu- commented Apr 18, 2016

@bluss I don't think performance is a concern here, the constructor is most likely only called with constant parameters anyway.

@tbu-
Copy link
Contributor Author

tbu- commented Apr 18, 2016

@GuillaumeGomez The constructor is a stable function, changing the return type is probably not an option. Also, as above, the constructor is most likely called with constant parameters, so it would mostly be a nuisance to require unwrapping a Result.

@TimNN
Copy link
Contributor

TimNN commented Apr 18, 2016

This change is probably not compatible with #33033.

@alexcrichton alexcrichton added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Apr 18, 2016
@alexcrichton
Copy link
Member

Sounds like something that's good to discuss! Currently this seems consistent with the rest of Duration but does indeed conflict with #33033. That being said I'm not sure why we'd want it as a const fn...

@oli-obk
Copy link
Contributor

oli-obk commented Apr 19, 2016

That being said I'm not sure why we'd want it as a const fn...

so we can declare constants like constant TWELVE_MINUTES: Duration = ?;

The assertion in const fn is the same issue (or at least similar to, since it's not a safety concern) as rust-lang/rfcs#1383

cc @pnkfelix

@alexcrichton
Copy link
Member

The libs team discussed this PR during triage today and the decision was to merge. Duration already does a bunch of other overflow checking, so it seems prudent to do so here as well.

Thanks again for the PR @tbu-!

@bors: r+ b25bb53

@bors
Copy link
Contributor

bors commented May 5, 2016

⌛ Testing commit b25bb53 with merge 0144bc5...

@bors
Copy link
Contributor

bors commented May 5, 2016

💔 Test failed - auto-win-gnu-32-opt

@tbu-
Copy link
Contributor Author

tbu- commented May 5, 2016

Failure seems unrelated.

@alexcrichton
Copy link
Member

@bors: retry

Maybe #33434?

@bors
Copy link
Contributor

bors commented May 6, 2016

⌛ Testing commit b25bb53 with merge 6301e22...

bors added a commit that referenced this pull request May 6, 2016
Panic on overflow in `Duration::new` constructor

Panicking on overflow is also done for `+`, and it replaces the
currently incorrect overflow behavior of wrapping around, which does not
make sense for `Duration`s.
@bors bors merged commit b25bb53 into rust-lang:master May 6, 2016
@crumblingstatue
Copy link
Contributor

This change is probably not compatible with #33033.

Here is an idea:
panic! could generate a compile error in a const context in const fns.

@oli-obk
Copy link
Contributor

oli-obk commented May 14, 2016

panic! could generate a compile error in a const context in const fns.

you've been beaten to it

@crumblingstatue
Copy link
Contributor

you've been beaten to it

Ah, good to know such a proposal already exists.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants