Skip to content

[4.2] Add constraints to FixedWidthInteger.Stride and .Magnitude (#17716) #17766

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

Conversation

stephentyrone
Copy link
Contributor

@stephentyrone stephentyrone commented Jul 5, 2018

  • 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
rdar://problem/41789616 [SR-8156]: Difficult to use random integers in generic contexts

Explanation: The primary motivation is to make it possible to use .random(in:) in generic contexts on FixedWidthInteger, without adding a pile of conformances. More generally, it brings the actual protocol more closely in-line with the documented semantics.
Scope: Adds (minor) additional requirements on any FixedWidthInteger type. These are all satisfied by all existing standard library types, and are already required by the documented semantics of FixedWidthInteger, if not explicitly by the protocol.
Issue: rdar://problem/41789616
Risk: Medium. This is an ABI change, but one that is unlikely to effect much (any?) third-party code.
Testing: Standard test suite, source compatibility test, compiler performance test (In #17716)
Reviewer: @lancep, @milseman, @lorentey

…#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
@stephentyrone
Copy link
Contributor Author

@swift-ci Please test

Copy link
Member

@milseman milseman left a comment

Choose a reason for hiding this comment

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

LGTM

@stephentyrone stephentyrone changed the title Add constraints to FixedWidthInteger.Stride and .Magnitude (#17716) [4.2] Add constraints to FixedWidthInteger.Stride and .Magnitude (#17716) Jul 5, 2018
Copy link
Member

@lorentey lorentey left a comment

Choose a reason for hiding this comment

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

👍

@lancep lancep self-requested a review July 5, 2018 19:17
@stephentyrone
Copy link
Contributor Author

@swift-ci please nominate

@airspeedswift airspeedswift merged commit 7699170 into swiftlang:swift-4.2-branch Jul 5, 2018
@swift-ci
Copy link
Contributor

swift-ci commented Jul 5, 2018

Build failed
Swift Test Linux Platform
Git Sha - b3ee047

@stephentyrone stephentyrone deleted the constrain-fixed-width-integer-4.2 branch July 6, 2018 01:46
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.

6 participants