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

[Nicola Salmoria]

On Fri, Jun 24, 2016 at 12:12 AM, Max Moiseev <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> 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
> > /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
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>

On Fri, Jun 24, 2016 at 12:12 AM, Max Moiseev <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> 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
> > /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
> > 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/345fbc51/attachment.html>