<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="" dir="auto"><div class="">That is an interesting point. Based on how the operators are defined for Int:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">‘<span style="color: rgb(65, 65, 65); font-family: Helvetica, Arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class="">Unlike the arithmetic operators in C and Objective-C, the Swift arithmetic operators do not allow values to overflow by default. You can opt in to value overflow behavior by using Swift’s overflow operators (such as </span><code class="code-voice" style="border: 0px; font-size: 0.85em; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline; color: rgb(128, 128, 128); font-family: Menlo, monospace; word-wrap: break-word;">a &+ b</code><span style="color: rgb(65, 65, 65); font-family: Helvetica, Arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class="">)</span><span style="color: rgb(65, 65, 65); font-family: Helvetica, Arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class="">’</span></div><div class=""><a href="https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/BasicOperators.html" class="">https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/BasicOperators.html</a></div></blockquote><div class=""><br class=""></div><div class="">The former statement, I believe, refers to the behaviour of throwing a runtime error. The solution would be the same as for checking before using an Array subscript (as currently implemented): explicit comparisons before performing the potentially crashing operation.</div><div class=""><br class=""></div><div class="">A regular signed integer already has the hazard of a ÷0 error. I think it would make sense to throw errors readily for subtraction - if the user would have to perform a check beforehand or face the consequences, just as they do for index out of bounds errors with Arrays. This is is currently how UInt's subtract implementation works, and I think the best option is to match this behaviour.</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 3 Feb 2016, at 21:51, Jonathan Tang <<a href="mailto:jonathan.d.tang@gmail.com" class="">jonathan.d.tang@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 3, 2016 at 9:31 AM, James Froggatt via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">In the standard library, there are methods (notably array subscripts, CollectionType's .count and the dimensions of CGSize) which are designed to deal only with natural (non-negative) numbers. Functions either throw an error if a parameter is negative, or else ignore the possibility of a negative value finding its way into these functions.<br class=""><br class="">By updating the standard library with a natural number type to represent these values (and potentially the Swift interfaces for Foundation and other frameworks), there is no way a negative number can be passed to these functions. This eliminates the need for many preconditions, allowing them to eliminate the possibility of a crash, and it would be clear that values such as count will never be negative.<br class=""><br class=""></blockquote><div class=""><br class=""></div><div class="">How would you handle the types of arithmetic operations? Natural numbers are not closed under subtraction or division; a natural number minus another natural number may be an integer. There's no provision for arithmetic operations to throw an error in Swift, so you might have to silently eat the error in the subtraction operation, which defeats much of the typesafety of having a separate type.</div></div></div></div></div></blockquote><div class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div></div></div></div></div></div></div></body></html>