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

Add OpAssign to Wrapping<T>, etc. in core::num::wrapping #30523

Merged
merged 3 commits into from
Jan 4, 2016
Merged

Add OpAssign to Wrapping<T>, etc. in core::num::wrapping #30523

merged 3 commits into from
Jan 4, 2016

Conversation

strega-nil
Copy link
Contributor

Add OpAssign to Wrapping, plus fix some problems in core::num::wrapping

including, but not limited to:

  • Testing Wrapping
  • Pull out a lot of broken code that doesn't need to be there with the new stage0 compiler
  • Adding Rem and RemAssign to Wrapping
  • Removed 3 (assumed accidental) re-exports, which is a minor [breaking-change].
  • Change shl and shr to take all integer types, instead of a usize; this is a more major [breaking-change], because of values that were inferred before, but brings us in line with the integer shifts.

Fixes #30524 and #30523

@rust-highfive
Copy link
Collaborator

r? @alexcrichton

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

@@ -88,6 +88,15 @@ macro_rules! wrapping_impl {
}
}

#[cfg(not(stage0))]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't AddAssign available in the new snapshot?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, right, I was developing this on the old snapshot by accident.

@bluss
Copy link
Member

bluss commented Dec 22, 2015

The rest of the PR looks fine to me. Please rename the PR to indicate that the main thing is adding the OpAssign implementations. Also note that the PR title is not included in bors' merge log, so I recommend just copying the title line to the first line of the PR message too.

@strega-nil strega-nil changed the title Fix some core::num::wrapping problems Add OpAssign to Wrapping<T>, etc. in core::num::wrapping Dec 22, 2015
@bluss
Copy link
Member

bluss commented Dec 22, 2015

Thanks! Note that the discussion in #27755 is not done yet, but it will recommend removing OverflowingOps as a trait. Touching it here doesn't change much, so it seems fine.

@alexcrichton
Copy link
Member

Thanks, looks good to me! Could you also squash the commits into one?

@bluss
Copy link
Member

bluss commented Dec 22, 2015

This needs the [breaking-change] tag in the commit log for the removal of pub on the functions in std::num::wrapping.

@sfackler
Copy link
Member

Is this good to go?

@strega-nil
Copy link
Contributor Author

@sfackler sorry, almost... I wanted to add some more impls.

@strega-nil
Copy link
Contributor Author

@sfackler unless you can think of anything more, I think it's done now, although obviously it needs a rebase.

@bluss
Copy link
Member

bluss commented Dec 30, 2015

The Wrapping<T> + T operations are fine with me, but what does the libs team think? (If there's been discussion already I must have missed it).

@glaebhoerl
Copy link
Contributor

I suggested the same thing here and people raised some valid points in response.

@strega-nil
Copy link
Contributor Author

@bluss @glaebhoerl We don't impl T + Wrapping<T>, only Wrapping<T> + T. The issue is one of ergonomics, and there's no arguing that Wrapping<T> + T should not output a Wrapping<T> and wrap. Our current way of doing things is awful; we need to fix it.

@eddyb
Copy link
Member

eddyb commented Jan 1, 2016

@bors r+

@bors
Copy link
Contributor

bors commented Jan 1, 2016

📌 Commit 165f5da has been approved by eddyb

@bors
Copy link
Contributor

bors commented Jan 1, 2016

⌛ Testing commit 165f5da with merge 68d1928...

@bors
Copy link
Contributor

bors commented Jan 1, 2016

💔 Test failed - auto-mac-64-nopt-t

@strega-nil
Copy link
Contributor Author

@bors @eddyb I found a bug with these new tests! :D

@strega-nil
Copy link
Contributor Author

@sfackler No, because we need to handle differently sized and signed types.

@glaebhoerl
Copy link
Contributor

@ubsan I'm not sure if I'm interpreting your next-to-last sentence right - are you saying type Output = Wrapping<T> is good, bad but preferable to the alternatives, something else...?

I don't have a strong opinion about this myself either way, but process-wise it feels wrong that there were concerns raised about this the last time it was suggested, and now it's just being added (and impl fors are insta-stable, right?). Things which are controversial shouldn't just slip through, I think.

(cc @llogiq @rkjnsn)

@llogiq
Copy link
Contributor

llogiq commented Jan 2, 2016

@glaebhoerl thanks for the ping. I'm not sure I understand the issue. Will have to wait until I get to my PC.

@bluss
Copy link
Member

bluss commented Jan 2, 2016

Yes, we need to have a discussion about the mixed operands.

@strega-nil
Copy link
Contributor Author

@glaebhoerl @llogiq I... just realized that Wrapping<T> is not unstable. I have no idea why I thought that. I'm going to do a different PR for the Add(Assign)?<T> for Wrapping<T>, so that there can be discussion there about it.

@eddyb
Copy link
Member

eddyb commented Jan 4, 2016

@bors r+

@bors
Copy link
Contributor

bors commented Jan 4, 2016

📌 Commit 402259d has been approved by eddyb

bors added a commit that referenced this pull request Jan 4, 2016
Add OpAssign to Wrapping<T>, plus fix some problems in core::num::wrapping

including, but not limited to:

* Testing Wrapping<T>
* Pull out a lot of broken code that doesn't need to be there with the new stage0 compiler
* Adding Rem and RemAssign to Wrapping<T>
* Removed 3 (assumed accidental) re-exports, which is a minor [breaking-change].
* Change shl and shr to take all integer types, instead of a usize; this is a more major [breaking-change], because of values that were inferred before, but brings us in line with the integer shifts.

Fixes #30524 and #30523
@bors
Copy link
Contributor

bors commented Jan 4, 2016

⌛ Testing commit 402259d with merge 50726c1...

@bors
Copy link
Contributor

bors commented Jan 4, 2016

💔 Test failed - auto-mac-64-opt

@glaebhoerl
Copy link
Contributor

FWIW I don't think Wrapping<T> += T is problematic -- there's really only one way it could behave and that behavior doesn't seem the least bit surprising -- but I'll let others weigh in (and there's no harm in delaying it, either).

@bluss
Copy link
Member

bluss commented Jan 4, 2016

@bors retry

@bors
Copy link
Contributor

bors commented Jan 4, 2016

⌛ Testing commit 402259d with merge 5e8cb38...

bors added a commit that referenced this pull request Jan 4, 2016
Add OpAssign to Wrapping<T>, plus fix some problems in core::num::wrapping

including, but not limited to:

* Testing Wrapping<T>
* Pull out a lot of broken code that doesn't need to be there with the new stage0 compiler
* Adding Rem and RemAssign to Wrapping<T>
* Removed 3 (assumed accidental) re-exports, which is a minor [breaking-change].
* Change shl and shr to take all integer types, instead of a usize; this is a more major [breaking-change], because of values that were inferred before, but brings us in line with the integer shifts.

Fixes #30524 and #30523
@bors bors merged commit 402259d into rust-lang:master Jan 4, 2016
bors added a commit that referenced this pull request Jan 6, 2016
Fix a breaking change in #30523

While this does fix a breaking change, it is also, technically, a
[breaking-change] to go back to our original way
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Wrapping<T> needs many different impls to make it useable