[4.2] Add constraints to FixedWidthInteger.Stride and .Magnitude (#17716) #17766
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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