> Now I'm confused. Isn't this line of the gyb returning .overflow when the > divisor is 0? > https://github.com/apple/swift/blob/master/test/Prototypes/Integers.swift.gyb#L793 > > <https://github.com/apple/swift/blob/master/test/Prototypes/Integers.swift.gyb#L793>
Sorry. What I meant was “this is how it’s documented”. Not dividing by zero is a precondition. > Also, the current version of Swift doesn't trap either: > let z = 0 > print(Int.divideWithOverflow(1, z)) // (0, true) > print(Int.remainderWithOverflow(1, z)) // (0, true) https://github.com/apple/swift/blob/master/stdlib/public/core/FixedPoint.swift.gyb#L399 Well, then we’ll be fixing it :-) > interestingly, you need to put 0 in a variable otherwise the compiler rejects > the lines. FWIW: Works in the Swift 3 compiler. > On Jun 24, 2016, at 3:03 PM, Nicola Salmoria <[email protected]> > wrote: > > > > On Fri, Jun 24, 2016 at 11:45 PM, Max Moiseev <[email protected] > <mailto:[email protected]>> wrote: >> 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. > > Now I'm confused. Isn't this line of the gyb returning .overflow when the > divisor is 0? > https://github.com/apple/swift/blob/master/test/Prototypes/Integers.swift.gyb#L793 > > <https://github.com/apple/swift/blob/master/test/Prototypes/Integers.swift.gyb#L793> > > Also, the current version of Swift doesn't trap either: > let z = 0 > print(Int.divideWithOverflow(1, z)) // (0, true) > print(Int.remainderWithOverflow(1, z)) // (0, true) > > interestingly, you need to put 0 in a variable otherwise the compiler rejects > the lines. > > >> 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. > > That would be my preference too. Thanks! > > Nicola > > > Thanks for your comments, Nicola! > > Max > >> On Jun 23, 2016, at 11:06 PM, Nicola Salmoria <[email protected] >> <mailto:[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
