<div dir="ltr">On Tue, Feb 21, 2017 at 3:27 PM, Max Moiseev via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Feb 21, 2017, at 1:15 PM, Patrick Pijnappel <<a href="mailto:patrickpijnappel@gmail.com" target="_blank">patrickpijnappel@gmail.com</a>> wrote:</div><br class="m_6289397770161147003Apple-interchange-newline"><div><div dir="ltr">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><div><br></div><div><b>Popcount & leadingZeroBits</b></div><div>- <i>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></span><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><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div>- <i>Naming: W</i>hy does <font face="monospace, monospace">popcount</font> retain the term of art? Considering it's relatively obscure it would seem <font face="monospace, monospace">numberOfOneBits</font> or something along those lines would be a more consistent choice.</div></div></div></blockquote></span>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.<span class=""><br><br><blockquote type="cite"><div><div dir="ltr"><div>Also, arguably shouldn't it be <font face="monospace, monospace">numberOfLeadingZeroBits</font>?</div></div></div></blockquote></span>There is countLeadingZeroBits for that.</div><div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div>I'm very happy with the inclusion of exposing these instructions btw, I've run into them lacking more than once before!<br></div></div></div></blockquote></span>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?</div></div></blockquote><div><br></div><div>So I for one have needed it. The question Jordan asked was interesting, because on reflection I've only needed it so far on concrete types. That said, in part that must be chalked up to integer generics not being really usable in the past.</div><div><br></div><div>On balance, MHO is that it's worthwhile to make it a protocol requirement (defaulted of course). It makes sense that all fixed-width integers have a popcount (and leadingZeroBits), just as they all have a bitWidth. Now, some fixed-width integers might not have a very optimized way of computing that popcount, but still. It is not out of the question that one would want to do some work based on the bits in a generic integer that has a fixed number of bits.</div><div><br></div><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><div dir="ltr"><div><b>FullWidth & ReportingOverflow</b></div><div>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">tableView(_:numberOfSections)</font> <wbr>is a lot more consistent with all other delegate methods.</div></div></div></blockquote></span>Joe recently sent an email on behalf of Dave to start this very discussion.</div><div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div><b>Division on Number?</b></div><div>The intro of the proposal puts division under Number, while the detailed design puts it under BinaryInteger, which is it?</div></div></div></blockquote></span>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></div><div>Max</div><span class=""><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 22, 2017 at 7:39 AM, Max Moiseev 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"><br><div><span><blockquote type="cite"><div>On Feb 18, 2017, at 12:02 PM, Karl Wagner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_6289397770161147003m_5331673711335459129m_-5714285844615251330Apple-interchange-newline"><div><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">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"></div></blockquote></span>SignedNumber will *not* be the same. It is just the same name.</div><div>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">here</a>).<span><br><blockquote type="cite"><div><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"><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">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><br></div><div>Why would you want Comparable?</div><div><br></div><div>Max</div><br></div><br>______________________________<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" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div>
</div></blockquote></div><br></span></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></div>