[swift-evolution] protocol-oriented integers (take 2)

Dave Abrahams dabrahams at apple.com
Tue Jan 31 11:33:36 CST 2017

on Mon Jan 30 2017, Brent Royal-Gordon <brent-AT-architechies.com> wrote:

>> On Jan 30, 2017, at 11:25 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>>> I mean that `OptionSet.RawValue` currently has to conform to
>>> `BitwiseOperations`, 
>> Actually it doesn't.  You just have to implement these yourself in that
>> case:
>>  extension OptionSet where Self.RawValue : BitwiseOperations {
> Oh, I didn't realize it was implemented that way (and was going to stay that way). Thanks for the
> correction.
>>> but would now need to conform to `BinaryInteger` (or a sub-protocol).
>> Does that limit you in some useful way?
> Well, a type like `Data` could be usefully conformed to
> `BitwiseOperations`, which would permit its use as a variable-sized
> bit buffer, but conforming it to `BinaryInteger` would make no sense
> and might cause mis-conformances. (For instance,
> `BinaryInteger.Type.+` and the `+` operator that works on
> `RangeReplaceableCollection`s like `Data` are incompatible). You would
> instead have to use a big-int type, but it's apparently common for
> those to be implemented in ways that make bitwise operations slow.

What's wrong with having Data (or most likely, a trivial wrapper over
Data) conform to SetAlgebra with Int elements?  You get the same

> However, unless I'm mistaken, I believe a `BitwiseOperations` protocol
> could be extracted from `BinaryInteger` later (right? Resilience
> permits you to add a new super-protocol and move some of the
> sub-protocol's requirements up into it?), so we can pick that up
> later.


More information about the swift-evolution mailing list