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@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 functionality. > 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. -- -Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution