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

[Max Moiseev]

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