<div dir="ltr"><table class="gmail-m_-7658466829875961545gmail-m_-8456667728193113819gmail-Bs gmail-m_-7658466829875961545gmail-m_-8456667728193113819gmail-nH gmail-m_-7658466829875961545gmail-m_-8456667728193113819gmail-iY" cellpadding="0" style="width:1448px"><tbody><tr><td class="gmail-m_-7658466829875961545gmail-m_-8456667728193113819gmail-Bu"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <span style="font-size:12.800000190734863px">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.</span></blockquote><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">Sensible, why didn't I think of that :).</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.800000190734863px">Also, arguably shouldn't it be </span><font face="monospace, monospace" style="font-size:12.800000190734863px">numberOfLeadingZeroBits</font><span style="font-size:12.800000190734863px">?<br></span></blockquote><span class="gmail-m_-7658466829875961545gmail-m_-8456667728193113819gmail-im">There is countLeadingZeroBits for that.</span></blockquote><div><br></div><div>I'm mean whether <font face="monospace, monospace">leadingZeroBits</font> should be named <font face="monospace, monospace">numberOfLeadingZeroBits</font>, I don't see any <font face="monospace, monospace">countLeadingZeroBits</font>. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.800000190734863px">Joe recently sent an email on behalf of Dave to start this very discussion.</span></blockquote><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">Yeah, that's the one I was responding to! I'm was talking more concretely about language support.</span></div></td></tr></tbody></table></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 22, 2017 at 10:18 AM, John McCall via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><blockquote type="cite"><div>On Feb 21, 2017, at 5:39 PM, Dave Abrahams <<a href="mailto:dabrahams@apple.com" target="_blank">dabrahams@apple.com</a>> wrote:</div><div><div dir="auto"><div><div>Sent from my moss-covered three-handled family gradunza</div></div><div><br>On Feb 21, 2017, at 10:08 AM, John McCall <<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><div><br><div><blockquote type="cite"><div>On Feb 21, 2017, at 2:15 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_6194899251862200358Apple-interchange-newline"><div><div dir="auto"><div><br><br><div>Sent from my moss-covered three-handled family gradunza</div></div><div><br>On Feb 21, 2017, at 9:04 AM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="auto" style="word-wrap:break-word">[Proposal: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md" target="_blank">https://github.com/apple/<wbr>swift-evolution/blob/master/<wbr>proposals/0104-improved-<wbr>integers.md</a>]<div><br></div><div>Hi, Max (and Dave). I did have some questions about this revision:</div><div><br></div><div><div><blockquote type="cite">Arithmetic and <wbr>SignedArithmetic protocols have been renamed to Number and SignedNumber.<br></blockquote><br></div><div>What happens to NSNumber here? It feels like the same problem as Character and (NS)CharacterSet.</div><div><br></div><div><br></div><div><div><blockquote type="cite">Endian-converting initializers and properties were added to the FixedWidthInteger <wbr>protocol.<br></blockquote><br></div>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. </div></div></div></div></blockquote><div><br></div><div>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.</div></div></div></blockquote><div><br></div>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.</div></div></blockquote><div><br></div>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 <i>is</i> a place of reduced emphasis for integers.</div></div></blockquote><div><br></div></span>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.</div><div><br></div><div>John.</div><div><div class="h5"><div><br><blockquote type="cite"><div><div dir="auto"><div><br><blockquote type="cite"><div><div>John.</div><div><br><blockquote type="cite"><div><div dir="auto"><br><blockquote type="cite"><div><div dir="auto" style="word-wrap:break-word"><div><div>Here's a sketch of such a thing:</div><div><br></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div dir="auto" style="word-wrap:break-word"><div><div>struct LittleEndian<Value: FixedWidthInteger> {</div></div></div><div dir="auto" style="word-wrap:break-word"><div><div> private var storage: Value</div></div></div><div dir="auto" style="word-wrap:break-word"><div><div><br></div></div></div><div dir="auto" style="word-wrap:break-word"><div><div> public var value: Value {</div></div></div><div dir="auto" style="word-wrap:break-word"><div><div>#if little_endian</div></div></div><div dir="auto" style="word-wrap:break-word"><div><div> return storage</div></div></div><div dir="auto" style="word-wrap:break-word"><div><div>#else</div></div></div><div dir="auto" style="word-wrap:break-word"><div><div> return swapBytes(storage)</div></div></div><div dir="auto" style="word-wrap:break-word"><div><div>#endif</div></div></div><div dir="auto" style="word-wrap:break-word"><div><div> }</div></div></div><div dir="auto" style="word-wrap:break-word"><div><div><br></div></div></div><div dir="auto" style="word-wrap:break-word"><div><div> public var bitPattern: Value {</div></div></div><div dir="auto" style="word-wrap:break-word"><div><div> return storage</div></div></div><div dir="auto" style="word-wrap:break-word"><div><div> }</div></div><div><br></div><div> public var asBigEndian: BigEndian<Value> {</div><div> return BigEndian(value: self.value)</div><div> }</div></div><div dir="auto" style="word-wrap:break-word"><div><div><br></div></div></div><div dir="auto" style="word-wrap:break-word"><div><div> public init(value: Value) {</div></div></div><div dir="auto" style="word-wrap:break-word"><div><div>#if little_endian</div></div></div><div dir="auto" style="word-wrap:break-word"><div><div> storage = value</div></div></div><div dir="auto" style="word-wrap:break-word"><div><div>#else</div></div></div><div dir="auto" style="word-wrap:break-word"><div><div> storage = swapBytes(value)</div></div></div><div dir="auto" style="word-wrap:break-word"><div><div>#endif</div></div></div><div dir="auto" style="word-wrap:break-word"><div><div> }</div></div></div><div dir="auto" style="word-wrap:break-word"><div><div><br></div></div></div><div dir="auto" style="word-wrap:break-word"><div><div> public init(bitPattern: Value) {</div></div></div><div dir="auto" style="word-wrap:break-word"><div><div> storage = bitPattern</div></div></div><div dir="auto" style="word-wrap:break-word"><div><div> }</div></div></div><div dir="auto" style="word-wrap:break-word"><div><div>}</div></div></div></blockquote><div dir="auto" style="word-wrap:break-word"><div><div><br></div><div>I'm not saying this is the <i>right</i> solution, just that I suspect adding Self-producing properties that change endianness is the wrong one.</div><br></div><div><blockquote type="cite"> /// The number of bits equal to 1 in this value's binary representation.<br> ///<br> /// For example, in a fixed-width integer type with a `bitWidth` value of 8,<br> /// the number 31 has five bits equal to 1.<br> ///<br> /// let x: Int8 = 0b0001_1111<br> /// // x == 31<br> /// // x.popcount == 5<br> var popcount: Int { get<div> }</div></blockquote><br></div><div>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.)</div></div></div></blockquote><div><br></div><div>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. </div><div><br></div><blockquote type="cite"><div><div dir="auto" style="word-wrap:break-word"><div><br></div><div>(I'm also still not happy with the non-Swifty name, but I see "populationCount" or "numberOfOneBits" would probably be worse.)</div><div><br></div><div><br></div><div>Thanks in advance,</div><div>Jordan</div></div></div></blockquote></div>______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></div></blockquote></div><br></div></blockquote></div></div></div></blockquote></div><br></div></div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>