-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Add constraints to FixedWidthInteger.Stride and .Magnitude #17716
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 constraints to FixedWidthInteger.Stride and .Magnitude #17716
Conversation
Add the constraint that these associatedtypes themselves conform to FixedWidthInteger and to SignedInteger and UnsignedInteger, respectively. These are effectively part of the semantic requirement of the protocol already, because the requirements on .min and .max effectively force FixedWidthInteger to be twos-complement, which requires Magnitude not be Self for signed types. Also, in practice it's generally necessary to have these two constraints in order to effectively use the FixedWidthInteger protocol anyway; witness that by adding them to the protocol, we eliminate them as constraints from a number of extensions. This also resolves https://bugs.swift.org/browse/SR-8156
@swift-ci test compiler performance |
Also, @airspeedswift if there's no perf regression, are you ok with pulling this into 4.2? |
@swift-ci please test |
@@ -2271,7 +2271,8 @@ extension BinaryInteger { | |||
/// other arithmetic methods and operators. | |||
public protocol FixedWidthInteger : | |||
BinaryInteger, LosslessStringConvertible | |||
where Magnitude : FixedWidthInteger | |||
where Magnitude : FixedWidthInteger & UnsignedInteger, | |||
Stride : FixedWidthInteger & SignedInteger |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpick: we usually don't align the :
s.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
boring =) I'll fix before committing.
|
Build failed |
How plausible is it that this could break source? Are there possible ways that you could be relying on not fulfilling these constraints and still get working code? |
@swift-ci please test source compatibility |
Linux failure unrelated? @swift-ci please test linux platform |
@airspeedswift Re: breaking source. It's relatively low-risk because practically any concrete type conforming to As far as generic code goes, any function definition that worked previously still works, and we haven't narrowed the set of candidate stdlib types at all, because they still conform to the same protocols, we just moved two requirements to the "right" place in the hierarchy. For anyone not defining their own integer types, it's a non-issue. |
@stephentyrone Would it help to make explicit in the documentation that |
@xwu Yeah, I'll give some thought to what the right way to document that is. We don't strictly require that the actual internal representation be twos-complement, rather that the API surface behaves as though it were. |
@swift-ci smoke test |
@xwu further improvement to documentation of |
LGTM basically. The one question I have is whether it's right to constrain |
@dabrahams All strides are signed: |
@@ -2271,7 +2271,8 @@ extension BinaryInteger { | |||
/// other arithmetic methods and operators. | |||
public protocol FixedWidthInteger : | |||
BinaryInteger, LosslessStringConvertible | |||
where Magnitude : FixedWidthInteger | |||
where Magnitude : FixedWidthInteger & UnsignedInteger, | |||
Stride : FixedWidthInteger & SignedInteger |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stephentyrone I'm referring to the line above. Either "& SignedInteger
" is redundant—in which case you should drop it—or you're constraining Stride
to be signed here. Or, I'm missing something ;-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What we get from Strideable
is SignedNumeric
. SignedInteger
is a very tiny refinement of BinaryInteger & SignedNumeric
, but I think it's the correct requirement semantically.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay then!
…#17716) * Add constraints to FixedWidthInteger.Stride and .Magnitude Add the constraint that these associatedtypes themselves conform to FixedWidthInteger and to SignedInteger and UnsignedInteger, respectively. These are effectively part of the semantic requirement of the protocol already, because the requirements on .min and .max effectively force FixedWidthInteger to be twos-complement, which requires Magnitude not be Self for signed types. Also, in practice it's generally necessary to have these two constraints in order to effectively use the FixedWidthInteger protocol anyway; witness that by adding them to the protocol, we eliminate them as constraints from a number of extensions. This also resolves https://bugs.swift.org/browse/SR-8156
…17766) * Add constraints to FixedWidthInteger.Stride and .Magnitude Add the constraint that these associatedtypes themselves conform to FixedWidthInteger and to SignedInteger and UnsignedInteger, respectively. These are effectively part of the semantic requirement of the protocol already, because the requirements on .min and .max effectively force FixedWidthInteger to be twos-complement, which requires Magnitude not be Self for signed types. Also, in practice it's generally necessary to have these two constraints in order to effectively use the FixedWidthInteger protocol anyway; witness that by adding them to the protocol, we eliminate them as constraints from a number of extensions. This also resolves https://bugs.swift.org/browse/SR-8156
Add the constraint that these associatedtypes themselves conform to FixedWidthInteger and to SignedInteger and UnsignedInteger, respectively. These are effectively part of the semantic requirement of the protocol already, because the requirements on .min and .max effectively force FixedWidthInteger to be twos-complement, which requires Magnitude not be Self for signed types. Also, in practice it's generally necessary to have these two constraints in order to effectively use the FixedWidthInteger protocol anyway; witness that by adding them to the protocol, we eliminate them as constraints from a number of extensions.
Resolves SR-8156.