<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><div>On Nov 1, 2017, at 14:54, Kelvin Ma via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 1, 2017 at 12:15 PM, Xiaodi Wu 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><span class="">On Wed, Nov 1, 2017 at 07:24 Daryle Walker <<a href="mailto:darylew@mac.com" target="_blank">darylew@mac.com</a>> wrote:<br></span><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><br><br><div id="m_1347555202612816606m_-8561303898083529502AppleMailSignature">Sent from my iPad</div></div><div dir="auto"><div><br>On Oct 31, 2017, at 10:55 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div><div>Right, these issues were discussed when the proposal was introduced and reviewed three times. In brief, what was once proposed as `Integer` was renamed `BinaryInteger` to avoid confusion in name between `Integer` and `Int`. It was also found to better reflect the semantics of the protocol, as certain functions treated the value not merely as an integer but operated specifically on its binary representation (for instance, the bitwise operators).</div><div><br></div><div>Do not confuse integers from their representation. Integers have no intrinsic radix and all integers have a binary representation. This is distinct from floating-point protocols, because many real values representable exactly as a decimal floating-point value cannot be represented exactly as a binary floating-point value.</div></div></div></blockquote><div><br></div></div><div dir="auto"><div>Abstractly, integers have representations in nearly all real radixes. But mandating base-2 properties for a numeric type that uses something else (ternary, negadecimal, non-radix, etc.) in its storage is definitely non-trivial. Hence the request for intermediate protocols that peel off the binary requirements. </div></div></blockquote><div dir="auto"><br></div></span><div dir="auto">Not only binary properties, but specifically two’s-complement binary properties. You are correct that some operations require thought for implementation if your type uses ternary storage, or for any type that does not specifically use two’s-complement representation internally, but having actually implemented them I can assure you it is not difficult to do correctly without even a CS degree.</div><div dir="auto"><br></div><div dir="auto">Again, one must distinguish between the actual representation in storage and semantics, which is what Swift protocols guarantee. The protocols are totally agnostic to the internal storage representation. The trade-off for supporting ternary _semantics_ is an additional set of protocols which complicates understanding and use in generic algorithms. I am not aware of tritwise operations being sufficiently in demand.<br></div></div></div></blockquote><div><br></div><div>Before everyone gets carried away with these protocols, can I ask what the real use case for ternary integers is? Also I’m not a fan of bikeshedding protocols for things that don’t exist (yet).</div></div></div></div></div></blockquote><br><div>I can’t imagine it’d ever get far enough for me to care about Swift’s stance on the issue, but I want to build a 9-“trit” breadboard computer some day, just for my own edification/amusement.</div><div><br></div><div>(FWIW, while I’m not 100% on how the integer protocols ended up, this isn’t the part that I’d change)</div><div><br></div><div>- Dave Sweeris</div></body></html>