<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=""><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><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></div></div></blockquote></div><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">Sorry. What I meant was “this is how it’s documented”. Not dividing by zero is a precondition.</div><div class="gmail_quote"><br class=""></div><div class="gmail_quote"><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Also, the current version of Swift doesn't trap either:<br class="">let z = 0<br class="">print(Int.divideWithOverflow(1, z)) // (0, true)<br class="">print(Int.remainderWithOverflow(1, z)) // (0, true)<br class=""></div></div></div></div></blockquote><a href="https://github.com/apple/swift/blob/master/stdlib/public/core/FixedPoint.swift.gyb#L399" class="">https://github.com/apple/swift/blob/master/stdlib/public/core/FixedPoint.swift.gyb#L399</a></div><div class="gmail_quote"><br class=""></div><div class="gmail_quote">Well, then we’ll be fixing it :-)</div><div class="gmail_quote"><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">interestingly, you need to put 0 in a variable otherwise the compiler rejects the lines.<br class=""></div></div></div></div></blockquote>FWIW: Works in the Swift 3 compiler.</div><div class="gmail_quote"><br class=""></div><div class="gmail_quote"><br class=""></div></div></div></div><div><blockquote type="cite" class=""><div class="">On Jun 24, 2016, at 3:03 PM, Nicola Salmoria <<a href="mailto:nicola.salmoria@gmail.com" class="">nicola.salmoria@gmail.com</a>> 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=""><<a href="mailto:moiseev@apple.com" target="_blank" class="">moiseev@apple.com</a>></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)) // (0, true)<br class="">print(Int.remainderWithOverflow(1, z)) // (0, true)<br class=""><br class=""></div><div class="">interestingly, you need to put 0 in a variable otherwise the compiler rejects the lines.<br class=""></div><div class=""> </div><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=""><br class=""></div><div class=""><span class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">If it is desirable that the WithOverflow methods never trap, then I think it would be better to add a `divisionByZero` case to the ArithmeticOverflow enum and return that instead of the generic `overflow`.</div></div></div></div></blockquote></span>Nice idea, but I don’t think it is really required that WithOverflow methods should never fail. The main idea behind these methods is to allow for 2 versions of arithmetic operations: one that traps on overflow and an unsafe one, that simply discards the overflow flag returning the partial result. Both of these however should, in my opinion, trap in a truly exceptional case of division by 0.</div></div></blockquote><div class=""><br class=""><div class="">That would be my preference too. Thanks!<br class=""><br class=""></div><div class="">Nicola<br class=""></div> </div><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=""><br class=""></div><div class="">Thanks for your comments, Nicola!</div><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">Max</div></font></span><div class=""><div class="h5"><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On Jun 23, 2016, at 11:06 PM, Nicola Salmoria <<a href="mailto:nicola.salmoria@gmail.com" target="_blank" class="">nicola.salmoria@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Jun 24, 2016 at 12:12 AM, Max Moiseev <span dir="ltr" class=""><<a href="mailto:moiseev@apple.com" target="_blank" class="">moiseev@apple.com</a>></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">Hi Nicola,<br class="">
<br class="">
> For these reasons, I think it would make sense to explicitly request that<br class="">
> the remainder operation never traps, and remove the overflow variants.<br class="">
It will still trap when you divide by 0. But in that case falling back to the same generic overflow logic is not the best idea.<br class="">
I agree that remainder is special, let me see what I can do about it.<br class="">
<br class=""></blockquote><div class=""><br class=""></div><div class="">LOL, yes of course, I forgot about the obvious trapping case.<br class=""><br class=""></div><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=""><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=""><br class=""></div><div class="">If it is desirable that the WithOverflow methods never trap, then I think it would be better to add a `divisionByZero` case to the ArithmeticOverflow enum and return that instead of the generic `overflow`.<br class=""><br class=""></div><div class="">Thanks,<br class=""></div><div class="">Nicola<br class=""></div><div class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks,<br class="">
Max<br class="">
<br class="">
<br class="">
> On Jun 23, 2016, at 2:38 PM, Nicola Salmoria via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
> Max Moiseev via swift-evolution <swift-evolution@...> writes:<br class="">
><br class="">
>>> For FixedWidthInteger#dividedWithOverflow/remainderWithOverflow, under<br class="">
> what situations would<br class="">
>> you have an overflow? I could only come up with something like<br class="">
> Int.min.dividedWithOverflow(-1).<br class="">
>> If you look at the prototype here:<br class="">
>><br class="">
> <a href="https://github.com/apple/swift/blob/master/test/Prototypes" rel="noreferrer" target="_blank" class="">https://github.com/apple/swift/blob/master/test/Prototypes</a><br class="">
> /Integers.swift.gyb#L789<br class="">
>> there is<br class="">
>> exactly the check that you’ve mentioned, but for all signed integers.<br class="">
> Besides, it is very convenient to<br class="">
>> have all the arithmetic operations be implemented the same way, even if<br class="">
> there were no real overflows for division.<br class="">
><br class="">
> I agree with this for the four basic operations, but not for the remainder<br class="">
> operation.<br class="">
><br class="">
> By definition, the remainder is always strictly smaller (in absolute value)<br class="">
> than the divisor, so even if the division itself overflows, the remainder<br class="">
> must be representable, so technically it never overflow.<br class="">
><br class="">
> In the only actual case where the division overflow, that is Int.min / -1,<br class="">
> the remainder is simply 0.<br class="">
><br class="">
> For these reasons, I think it would make sense to explicitly request that<br class="">
> the remainder operation never traps, and remove the overflow variants.<br class="">
><br class="">
> Nicola<br 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/mailman/listinfo/swift-evolution</a><br class="">
<br class="">
</blockquote></div><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Jun 24, 2016 at 12:12 AM, Max Moiseev <span dir="ltr" class=""><<a href="mailto:moiseev@apple.com" target="_blank" class="">moiseev@apple.com</a>></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">Hi Nicola,<br class="">
<br class="">
> For these reasons, I think it would make sense to explicitly request that<br class="">
> the remainder operation never traps, and remove the overflow variants.<br class="">
It will still trap when you divide by 0. But in that case falling back to the same generic overflow logic is not the best idea.<br class="">
I agree that remainder is special, let me see what I can do about it.<br class="">
<br class="">
Thanks,<br class="">
Max<br class="">
<br class="">
<br class="">
> On Jun 23, 2016, at 2:38 PM, Nicola Salmoria via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
> Max Moiseev via swift-evolution <swift-evolution@...> writes:<br class="">
><br class="">
>>> For FixedWidthInteger#dividedWithOverflow/remainderWithOverflow, under<br class="">
> what situations would<br class="">
>> you have an overflow? I could only come up with something like<br class="">
> Int.min.dividedWithOverflow(-1).<br class="">
>> If you look at the prototype here:<br class="">
>><br class="">
> <a href="https://github.com/apple/swift/blob/master/test/Prototypes" rel="noreferrer" target="_blank" class="">https://github.com/apple/swift/blob/master/test/Prototypes</a><br class="">
> /Integers.swift.gyb#L789<br class="">
>> there is<br class="">
>> exactly the check that you’ve mentioned, but for all signed integers.<br class="">
> Besides, it is very convenient to<br class="">
>> have all the arithmetic operations be implemented the same way, even if<br class="">
> there were no real overflows for division.<br class="">
><br class="">
> I agree with this for the four basic operations, but not for the remainder<br class="">
> operation.<br class="">
><br class="">
> By definition, the remainder is always strictly smaller (in absolute value)<br class="">
> than the divisor, so even if the division itself overflows, the remainder<br class="">
> must be representable, so technically it never overflow.<br class="">
><br class="">
> In the only actual case where the division overflow, that is Int.min / -1,<br class="">
> the remainder is simply 0.<br class="">
><br class="">
> For these reasons, I think it would make sense to explicitly request that<br class="">
> the remainder operation never traps, and remove the overflow variants.<br class="">
><br class="">
> Nicola<br 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/mailman/listinfo/swift-evolution</a><br class="">
<br class="">
</blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></body></html>