Skip to content

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
Contributor

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.
@tbu- tbu- force-pushed the pr_duration_new_overflow branch from b975c3c to b25bb53 Compare April 18, 2016 10:41
@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
Contributor

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
Collaborator

bors commented May 5, 2016

⌛ Testing commit b25bb53 with merge 0144bc5...

@bors
Copy link
Collaborator

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
Collaborator

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