> On Jun 23, 2016, at 23:06, Nicola Salmoria via swift-evolution > <swift-evolution@swift.org> wrote: > > > > On Fri, Jun 24, 2016 at 12:12 AM, Max Moiseev <mois...@apple.com > <mailto:mois...@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
