<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 Jun 24, 2016, at 15:03, Nicola Salmoria via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Jun 24, 2016 at 11:45 PM, Max Moiseev <span dir="ltr" class="">&lt;<a href="mailto:moiseev@apple.com" target="_blank" class="">moiseev@apple.com</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">However, division by 0 isn't an overflow: it's an undefined operation. I find it somewhat surprising that dividedWithOverflow/remainderWithOverflow allow attempting this operation.<br class=""></div></div></div></div></blockquote></span>I tried to say that in my previous email. I agree that division by zero is NOT the overflow and should probably be handled differently if only for a better error message.</div><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">To me, the intuitive semantics of the WithOverflow methods are "perform the operation, and if the result doesn't fit in the given type, return a truncated result and an overflow flag". This is not what happens when dividing by 0, because the result simply doesn't exist.<br class=""></div><div class=""><br class=""></div><div class="">I think I would prefer if rhs != 0 was documented as an explicit precondition of the division and remainder operations, and dividedWithOverflow/remainderWithOverflow trapped because of precondition failure.<br class=""></div></div></div></div></blockquote></span>That’s exactly how it is implemented in the prototype now.</div></div></blockquote><div class=""><br class=""></div><div class="">Now I'm confused. Isn't this line of the gyb returning .overflow when the divisor is 0?<br class=""><a href="https://github.com/apple/swift/blob/master/test/Prototypes/Integers.swift.gyb#L793" class="">https://github.com/apple/swift/blob/master/test/Prototypes/Integers.swift.gyb#L793</a><br class=""></div><div class=""><br class=""></div><div class="">Also, the current version of Swift doesn't trap either:<br class="">let z = 0<br class="">print(Int.divideWithOverflow(1, z))&nbsp;&nbsp;&nbsp; // (0, true)<br class="">print(Int.remainderWithOverflow(1, z))&nbsp;&nbsp;&nbsp; // (0, true)<br class=""><br class=""></div><div class="">interestingly, you need to put 0 in a variable otherwise the compiler rejects the lines.</div></div></div></div></div></blockquote><br class=""></div><div>Huh. My bad for not checking. Yeah, I don't think dividing by zero and dividing INT_MIN by -1 are the same kind of overflow.</div><div><br class=""></div><div>Jordan</div></body></html>