[swift-evolution] [Review] SE-0104: Protocol-oriented integers

[Max Moiseev]

> 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.
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.

> 
> 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.
> 
> 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.
That’s exactly how it is implemented in the prototype now.

> 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`.
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.

Thanks for your comments, Nicola!

Max

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160624/62e10a01/attachment.html>