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

[Jordan Rose]

> On Jun 23, 2016, at 23:06, Nicola Salmoria via swift-evolution <swift-evolution at swift.org> 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`.

IIUC, the WithOverflow flag is only for the INT_MIN / -1 case. (And IIUC, that doesn't affect remainder.)

Jordan

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