Arbitrary sized signed -1 can have different popcount depending on the > underlying buffer length (if there is a buffer) even if it’s the same type > and the same value. Same with leading zeros, as the underlying > representation is unbounded on the more significant side.
Sensible, why didn't I think of that :). > Also, arguably shouldn't it be numberOfLeadingZeroBits? >> > There is countLeadingZeroBits for that. I'm mean whether leadingZeroBits should be named numberOfLeadingZeroBits, I don't see any countLeadingZeroBits. Joe recently sent an email on behalf of Dave to start this very discussion. Yeah, that's the one I was responding to! I'm was talking more concretely about language support. On Wed, Feb 22, 2017 at 10:18 AM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: > On Feb 21, 2017, at 5:39 PM, Dave Abrahams <dabrah...@apple.com> wrote: > Sent from my moss-covered three-handled family gradunza > > On Feb 21, 2017, at 10:08 AM, John McCall <rjmcc...@apple.com> wrote: > > > On Feb 21, 2017, at 2:15 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Sent from my moss-covered three-handled family gradunza > > On Feb 21, 2017, at 9:04 AM, Jordan Rose <jordan_r...@apple.com> wrote: > > [Proposal: https://github.com/apple/swift-evolution/blob/master/ > proposals/0104-improved-integers.md] > > Hi, Max (and Dave). I did have some questions about this revision: > > Arithmetic and SignedArithmetic protocols have been renamed > to Number and SignedNumber. > > > What happens to NSNumber here? It feels like the same problem as Character > and (NS)CharacterSet. > > > Endian-converting initializers and properties were added to > the FixedWidthInteger protocol. > > > This is the thing I have the biggest problem with. Endian conversions > aren't numeric operations, and you can't meaningfully mix numbers of > different endianness. That implies to me that numbers with different > endianness should have different types. I think there's a design to explore > with LittleEndian<Int> and BigEndian<Int>, and explicitly using those types > whenever you need to convert. > > > I disagree. Nobody actually wants to compute with numbers in the wrong > endianness for the machine. This is just used for corrections at the ends > of wire protocols, where static type has no meaning. > > > I think Jordan's suggestion is not that LittleEndian<Int> or > BigEndian<Int> would be artihmetic types, but that they would be different > types, primarily opaque, that can be explicitly converted to/from Int. > When you read something off the wire, you ask for the bytes as one of those > two types (as appropriate) and then convert to the underlying type. > Ideally, Int doesn't even conform to the "this type can be read off the > wire" protocol, eliminating the common mistake of serializing something > using native endianness. > > > Still, you have to implement those somehow. How do you do that without > this functionality in the Integer API? Turtles have to stop somewhere. We > could de-emphasize these APIs by making them static, but "x.yyyy" already > *is* a place of reduced emphasis for integers. > > > That's fair. I don't object to having methods for these as long as they > aren't the encouraged way of working with byte-swapped integers. > > John. > > > John. > > > Here's a sketch of such a thing: > > struct LittleEndian<Value: FixedWidthInteger> { > private var storage: Value > > public var value: Value { > #if little_endian > return storage > #else > return swapBytes(storage) > #endif > } > > public var bitPattern: Value { > return storage > } > > public var asBigEndian: BigEndian<Value> { > return BigEndian(value: self.value) > } > > public init(value: Value) { > #if little_endian > storage = value > #else > storage = swapBytes(value) > #endif > } > > public init(bitPattern: Value) { > storage = bitPattern > } > } > > > I'm not saying this is the *right* solution, just that I suspect adding > Self-producing properties that change endianness is the wrong one. > > /// The number of bits equal to 1 in this value's binary representation. > /// > /// For example, in a fixed-width integer type with a `bitWidth` value > of 8, > /// the number 31 has five bits equal to 1. > /// > /// let x: Int8 = 0b0001_1111 > /// // x == 31 > /// // x.popcount == 5 > var popcount: Int { get > } > > > Is this property actually useful enough to put into a protocol? I know > it's defaulted, but it's already an esoteric operation; it seems unlikely > that one would need it in a generic context. (It's also definable for > arbitrary UnsignedIntegers as well as arbitrary FixedWidthIntegers.) > > > The whole point is that you want to dispatch down to an LLVM instruction > for this and not rely on the optimizer to collapse your loop into one. > > > (I'm also still not happy with the non-Swifty name, but I see > "populationCount" or "numberOfOneBits" would probably be worse.) > > > Thanks in advance, > Jordan > > _______________________________________________ > 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 > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution