> 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 <[email protected]> > wrote: > > > > On Fri, Jun 24, 2016 at 12:12 AM, Max Moiseev <[email protected] > <mailto:[email protected]>> 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 > > <[email protected] <mailto:[email protected]>> wrote: > > > > Max Moiseev via swift-evolution <swift-evolution@...> 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 > > [email protected] <mailto:[email protected]> > > 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 <[email protected] > <mailto:[email protected]>> 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 > > <[email protected] <mailto:[email protected]>> wrote: > > > > Max Moiseev via swift-evolution <swift-evolution@...> 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 > > [email protected] <mailto:[email protected]> > > https://lists.swift.org/mailman/listinfo/swift-evolution > > <https://lists.swift.org/mailman/listinfo/swift-evolution> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
