Sent from my moss-covered three-handled family gradunza
> On Feb 21, 2017, at 10:08 AM, John McCall <[email protected]> wrote: > > >> On Feb 21, 2017, at 2:15 PM, Dave Abrahams via swift-evolution >> <[email protected]> wrote: >> >> >> >> Sent from my moss-covered three-handled family gradunza >> >>> On Feb 21, 2017, at 9:04 AM, Jordan Rose <[email protected]> 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. > 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
