I don&#39;t think this is necessary for any generic algorithms. There is already quotientAndRemainder for your use for integers, and floating point division works differently. I don&#39;t think .0 works in any case. Fundamentally, your idea would turn integers into ersatz rational numbers, but one of the purposes of these protocols is to make it easy to make your own rational type if the need arises. My understanding of the goal here is to model what integers can already do, not to give them new functions.<br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 16, 2017 at 17:06 David Sweeris &lt;<a href="mailto:davesweeris@mac.com">davesweeris@mac.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">On Jan 16, 2017, at 13:40, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div dir="ltr" class="gmail_msg">On Mon, Jan 16, 2017 at 12:02 PM, Stephen Canon <span dir="ltr" class="gmail_msg">&lt;<a href="mailto:scanon@apple.com" class="gmail_msg" target="_blank">scanon@apple.com</a>&gt;</span> wrote:<br class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><span class="m_-6833189436833417978gmail- gmail_msg"><blockquote type="cite" class="gmail_msg">On Jan 16, 2017, at 3:25 AM, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br class="gmail_msg"></blockquote><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div style="font-family:helvetica;font-size:12px;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="gmail_msg"><br class="m_-6833189436833417978gmail-m_7691912612560415340Apple-interchange-newline gmail_msg">Unless I&#39;m mistaken, after removing division, models of SignedArithmetic would have the mathematical properties of a ring. For every element a in ring R, there must exist an additive inverse -a in R such that a + (-a) = 0. Models of Arithmetic alone would not necessarily have that property.</div></div></blockquote></div><br class="gmail_msg"></span><div class="gmail_msg">Closure under the arithmetic operations is a sticky point for all the finite integer models vs. the actual ring axioms.  No finite [non-modulo] integer type is closed, because of overflow. Similarly, additive inverses don’t exist for the most negative value of a signed type,</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I think this goes back to the distinct mentioned earlier: imperfection in how we model something, or a difference in what we&#39;re modeling? Finite memory will dictate that any model that attempts to represent integers will face constraints. Signed integer types represent a best-effort attempt at exactly representing the greatest possible number of integers within a given amount of memory such that the greatest proportion of those have an additive inverse that can be also be represented in the same amount of memory.</div><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">or for any non-zero value of an unsigned type.</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">This is not fundamentally attributable to a limitation of how we model something. Non-zero values of unsigned type do not have additive inverses in the same way that non-one values of unsigned type do not have multiplicative inverses.</div><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">The obvious way around this is to say that types conforming to Arithmetic model a subset of a ring that need not be closed under the operations.</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">If we don&#39;t remove division, type conforming to Arithmetic would also model a subset of a field that need not be closed under the operations. I&#39;m not sure it&#39;d be wise to put such a mathematical definition on it with a &quot;need not&quot; like that. Better, IMO, to give these protocols semantics based on a positive description of the axioms that do hold--with the caveat that the result of addition and multiplication will hold to these axioms only insofar as the result does not overflow.</div></div></div></div></blockquote><br class="gmail_msg"></div><div dir="auto" class="gmail_msg"><div class="gmail_msg">What about writing the division part of the protocol so that the return type isn&#39;t necessarily `Self`?</div><div class="gmail_msg">protocol Arithmetic {</div><div class="gmail_msg">    associatedtype DivisionResult</div><div class="gmail_msg">    // use a function instead of an operator to avoid making this the mother of all breaking changes</div><div class="gmail_msg">    ...</div><div class="gmail_msg">    static func divide (_: Self, _: Self) -&gt; Self.DivisionResult</div><div class="gmail_msg">    ...</div><div class="gmail_msg">}</div><div class="gmail_msg">extension FloatingPoint {</div><div class="gmail_msg">    typealias <span style="background-color:rgba(255,255,255,0)" class="gmail_msg">DivisionResult = Self</span></div><div class="gmail_msg"><span style="background-color:rgba(255,255,255,0)" class="gmail_msg">}</span></div><div class="gmail_msg"><span style="background-color:rgba(255,255,255,0)" class="gmail_msg">extension Integer {</span></div><div class="gmail_msg"><span style="background-color:rgba(255,255,255,0)" class="gmail_msg">    typealias DivisionResult = (quotient: Self, remainder: Self)</span></div><div class="gmail_msg"><span style="background-color:rgba(255,255,255,0)" class="gmail_msg">}</span></div><div class="gmail_msg">That way, Integer division returns the &quot;correct&quot; answer regardless of whether the numerator is a multiple of the denominator.</div><div class="gmail_msg">In generic algorithms, you could easily extract the &quot;normal&quot; value like this:</div><div class="gmail_msg">    let tValue = T.divide(x, y).0</div><div class="gmail_msg">because the `.0` of a non-tuple value is just the original value, right?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">One thing I&#39;m not sure about (and can&#39;t check because I&#39;m not in front of a computer) is how this would affect multiplication... Would we want `Self` and `Self.DivisionResult` to be mutually multipliable?</div><div class="gmail_msg"><div class="gmail_msg"><span style="background-color:rgba(255,255,255,0)" class="gmail_msg">protocol Arithmetic {</span></div><div class="gmail_msg"><span style="background-color:rgba(255,255,255,0)" class="gmail_msg">    associatedtype DivisionResult</span></div><div class="gmail_msg"><span style="background-color:rgba(255,255,255,0)" class="gmail_msg">    ...</span></div><div class="gmail_msg"><span style="background-color:rgba(255,255,255,0)" class="gmail_msg">    static func divide (_: Self, _: Self) -&gt; Self.DivisionResult</span></div><div class="gmail_msg"><span style="background-color:rgba(255,255,255,0)" class="gmail_msg">    static func * (_: Self, _: Self) -&gt; Self</span></div><div class="gmail_msg"><span style="background-color:rgba(255,255,255,0)" class="gmail_msg">    static func * (_: Self, _: Self.DivisionResult) -&gt; Self</span></div><div class="gmail_msg"><span style="background-color:rgba(255,255,255,0)" class="gmail_msg">    static func * (_: Self.DivisionResult, _: Self) -&gt; Self</span></div><div class="gmail_msg"><span style="background-color:rgba(255,255,255,0)" class="gmail_msg">}</span></div></div><div class="gmail_msg"><span style="background-color:rgba(255,255,255,0)" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg"><span style="background-color:rgba(255,255,255,0)" class="gmail_msg">Could the compiler figure out that, where Self.DivisionResult == Self, those three * functions are actually just one function, or, whenever you tried to actually multiply stuff, would it throw its hands in the air (like it just don&#39;t care) and complain about ambiguous references to &quot;*&quot;?</span></div><div class="gmail_msg"><span style="background-color:rgba(255,255,255,0)" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg"><span style="background-color:rgba(255,255,255,0)" class="gmail_msg">- Dave Sweeris</span></div></div></blockquote></div>