On Mon, Jan 30, 2017 at 10:08 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> 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. > Having implemented a bit vector in Swift (then found it to be slow, then asked for leadingZeros the last time this proposal came round), I totally agree that it would be one such type that conforms to the syntax and semantics of `BitwiseOperations`. I was initially bummed to see it go as well, but on reflection I think it's the right decision. The question is, what interesting algorithm could you actually write that would be generic over BitwiseOperations? I couldn't think of any. Sure, I could use an Int like a BitVector, but if I wanted to use the instance only for bitwise operations, I'd just use a word-sized BitVector. Perhaps you have other use cases? > 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. > > -- > Brent Royal-Gordon > Architechies > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution