[Pitch] Conditionally Conform Range and ClosedRange to BitwiseCopyable

Evolution Pitches
1

I'm not sure if this actually requires evolution to do, but as neither type has a deinit and both merely contain two Bounds, it seems reasonable to me that they should both conditionally conform to BitwiseCopyable.

extension Range: BitwiseCopyable where Bound: BitwiseCopyable { }
extension ClosedRange: BitwiseCopyable where Bound: BitwiseCopyable { }
7 Likes
2

Should the partial range types be included?

extension PartialRangeFrom: BitwiseCopyable where Bound: BitwiseCopyable { }
extension PartialRangeUpTo: BitwiseCopyable where Bound: BitwiseCopyable { }
extension PartialRangeThrough: BitwiseCopyable where Bound: BitwiseCopyable { }

Could the CollectionOfOne type also be included?
(So that we can access its span.bytes property.)

extension CollectionOfOne: BitwiseCopyable where Element: BitwiseCopyable { }
2 Likes
3

Sorry for missing this earlier @Nobody1707. I agree that these should be added. The Range family and CollectionOfOne should clearly have conditional conformances to BitwiseCopyable.

Other misses are Slice<UnsafeRawBufferPointer>, FloatingPointRoundingRule (it is not frozen, but should be BitwiseCopyable anyway) and POSIXErrorCode.

To my eyes, these seem like they could be bug fixes.

I noticed the Range and Slice issue late in the fall, but haven't gotten to it yet.

1 Like
4

Since BitwiseCopyable has shipped, I'd imagine this needs a little amendment/review but should not be onerous :)

1 Like
5

I don't think these need review, but it is an amendment.

3 Likes
6

I created a GitHub issue to track this:

If you notice other missing types, don't hesitate to add them to the issue!

6 Likes