<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 24, 2016 at 12:12 AM, Max Moiseev <span dir="ltr"><<a href="mailto:moiseev@apple.com" target="_blank">moiseev@apple.com</a>></span> wrote:<br><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>
<br>
> For these reasons, I think it would make sense to explicitly request that<br>
> the remainder operation never traps, and remove the overflow variants.<br>
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>
I agree that remainder is special, let me see what I can do about it.<br>
<br></blockquote><div><br></div><div>LOL, yes of course, I forgot about the obvious trapping case.<br><br></div><div>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><br></div><div>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></div><div><br></div><div>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><br></div><div>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><br></div><div>Thanks,<br></div><div>Nicola<br></div><div><br></div><div> </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>
Max<br>
<br>
<br>
> On Jun 23, 2016, at 2:38 PM, Nicola Salmoria via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> Max Moiseev via swift-evolution <swift-evolution@...> writes:<br>
><br>
>>> For FixedWidthInteger#dividedWithOverflow/remainderWithOverflow, under<br>
> what situations would<br>
>> you have an overflow? I could only come up with something like<br>
> Int.min.dividedWithOverflow(-1).<br>
>> If you look at the prototype here:<br>
>><br>
> <a href="https://github.com/apple/swift/blob/master/test/Prototypes" rel="noreferrer" target="_blank">https://github.com/apple/swift/blob/master/test/Prototypes</a><br>
> /Integers.swift.gyb#L789<br>
>> there is<br>
>> exactly the check that you’ve mentioned, but for all signed integers.<br>
> Besides, it is very convenient to<br>
>> have all the arithmetic operations be implemented the same way, even if<br>
> there were no real overflows for division.<br>
><br>
> I agree with this for the four basic operations, but not for the remainder<br>
> operation.<br>
><br>
> By definition, the remainder is always strictly smaller (in absolute value)<br>
> than the divisor, so even if the division itself overflows, the remainder<br>
> must be representable, so technically it never overflow.<br>
><br>
> In the only actual case where the division overflow, that is Int.min / -1,<br>
> the remainder is simply 0.<br>
><br>
> For these reasons, I think it would make sense to explicitly request that<br>
> the remainder operation never traps, and remove the overflow variants.<br>
><br>
> Nicola<br>
> _______________________________________________<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/mailman/listinfo/swift-evolution</a><br>
<br>
</blockquote></div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 24, 2016 at 12:12 AM, Max Moiseev <span dir="ltr"><<a href="mailto:moiseev@apple.com" target="_blank">moiseev@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Nicola,<br>
<br>
> For these reasons, I think it would make sense to explicitly request that<br>
> the remainder operation never traps, and remove the overflow variants.<br>
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>
I agree that remainder is special, let me see what I can do about it.<br>
<br>
Thanks,<br>
Max<br>
<br>
<br>
> On Jun 23, 2016, at 2:38 PM, Nicola Salmoria via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> Max Moiseev via swift-evolution <swift-evolution@...> writes:<br>
><br>
>>> For FixedWidthInteger#dividedWithOverflow/remainderWithOverflow, under<br>
> what situations would<br>
>> you have an overflow? I could only come up with something like<br>
> Int.min.dividedWithOverflow(-1).<br>
>> If you look at the prototype here:<br>
>><br>
> <a href="https://github.com/apple/swift/blob/master/test/Prototypes" rel="noreferrer" target="_blank">https://github.com/apple/swift/blob/master/test/Prototypes</a><br>
> /Integers.swift.gyb#L789<br>
>> there is<br>
>> exactly the check that you’ve mentioned, but for all signed integers.<br>
> Besides, it is very convenient to<br>
>> have all the arithmetic operations be implemented the same way, even if<br>
> there were no real overflows for division.<br>
><br>
> I agree with this for the four basic operations, but not for the remainder<br>
> operation.<br>
><br>
> By definition, the remainder is always strictly smaller (in absolute value)<br>
> than the divisor, so even if the division itself overflows, the remainder<br>
> must be representable, so technically it never overflow.<br>
><br>
> In the only actual case where the division overflow, that is Int.min / -1,<br>
> the remainder is simply 0.<br>
><br>
> For these reasons, I think it would make sense to explicitly request that<br>
> the remainder operation never traps, and remove the overflow variants.<br>
><br>
> Nicola<br>
> _______________________________________________<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/mailman/listinfo/swift-evolution</a><br>
<br>
</blockquote></div><br></div>