<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 21, 2017, at 1:15 PM, Patrick Pijnappel <<a href="mailto:patrickpijnappel@gmail.com" class="">patrickpijnappel@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I've followed this for a long time and work a lot with number/big num related code, and I must say I'm really excited about the way this is turning out!<br class=""><div class=""><br class=""></div><div class=""><b class="">Popcount & leadingZeroBits</b></div><div class="">- <i class="">Placement:</i> What's the rationale behind placing popcount & clz on fixed width integer instead of BinaryInteger? It seems implementing these would be trivial also for BigInt types.</div></div></div></blockquote><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">- <i class="">Naming: W</i>hy does <font face="monospace, monospace" class="">popcount</font> retain the term of art? Considering it's relatively obscure it would seem <font face="monospace, monospace" class="">numberOfOneBits</font> or something along those lines would be a more consistent choice.</div></div></div></blockquote>The thinking was something like: people who know it, know it by this name and will be a little annoyed, people who don’t know what it is, and simply want their stack overflow snippet to work, will not be able to identify it under any other name. So a non-term-of-art name would not really benefit anyone, other than our naming guidelines.<br class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Also, arguably shouldn't it be <font face="monospace, monospace" class="">numberOfLeadingZeroBits</font>?</div></div></div></blockquote>There is countLeadingZeroBits for that.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">I'm very happy with the inclusion of exposing these instructions btw, I've run into them lacking more than once before!<br class=""></div></div></div></blockquote>What would you say about popcount being a protocol requirement? If you’ve needed it, was it in the generic context or on concrete types?<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class=""><b class="">FullWidth & ReportingOverflow</b></div><div class="">That's pretty clever there with the trailing argument :). Do you know whether there is any technical reason why we couldn't support a trailing 'argument label' without actual argument directly in the language? If not I might want to write up a proposal for that because if run into wanting this for a longer time. E.g. delegate methods would be a very common case: <font face="monospace, monospace" class="">tableView(_:numberOfSections)</font> <wbr class="">is a lot more consistent with all other delegate methods.</div></div></div></blockquote>Joe recently sent an email on behalf of Dave to start this very discussion.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class=""><b class="">Division on Number?</b></div><div class="">The intro of the proposal puts division under Number, while the detailed design puts it under BinaryInteger, which is it?</div></div></div></blockquote>It is one of the most recent changes, division is *not* in the Number. It was moved down the hierarchy to BinaryInteger. I’ll fix the proposal. Thanks!</div><div><br class=""></div><div>Max</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Feb 22, 2017 at 7:39 AM, Max Moiseev via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Feb 18, 2017, at 12:02 PM, Karl Wagner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_5331673711335459129m_-5714285844615251330Apple-interchange-newline"><div class=""><span style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">I assume the “SignedNumber” protocol is the same as the existing one in the standard library. That is to say, Strideable.Stride will now conform to Number and have operators.</span><br style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""></div></blockquote></span>SignedNumber will *not* be the same. It is just the same name.</div><div class="">Stride will have operators, yes. Strideable in general will not, unless it’s a _Pointer. (you can find the current implementation prototype <a href="https://github.com/apple/swift/blob/new-integer-protocols/stdlib/public/core/Stride.swift.gyb" target="_blank" class="">here</a>).<span class=""><br class=""><blockquote type="cite" class=""><div class=""><br style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">Also minor nitpick, would it be too onerous to require Number.Magnitude to be Comparable? Currently it’s only Equatable and ExpressibleByIntegerLiteral.</span></div></blockquote></span>Magnitude is supposed to conform to Arithmetic (or Number, or whatever it ends up being called), but the recursive constraints feature is missing, therefore we constrained it with the protocols that Arithmetic itself refines.</div><div class=""><br class=""></div><div class="">Why would you want Comparable?</div><div class=""><br class=""></div><div class="">Max</div><br class=""></div><br class="">______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></body></html>