<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 3, 2016 at 2:17 PM, James Samuel Froggatt <span dir="ltr">&lt;<a href="mailto:conductator@ntlworld.com" target="_blank">conductator@ntlworld.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" dir="auto"><div>That is an interesting point. Based on how the operators are defined for Int:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>‘<span style="color:rgb(65,65,65);font-family:Helvetica,Arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">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 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 &amp;+ b</code><span style="color:rgb(65,65,65);font-family:Helvetica,Arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">)</span><span style="color:rgb(65,65,65);font-family:Helvetica,Arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)">’</span></div><div><a href="https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/BasicOperators.html" target="_blank">https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/BasicOperators.html</a></div></blockquote><div><br></div><div>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><br></div><div>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&#39;s subtract implementation works, and I think the best option is to match this behaviour.</div><span class=""><div><br></div><br></span></div></blockquote><div><br></div><div>We&#39;d be largely in the same position we are in now w.r.t. array accesses.  You still need a runtime check and you can still cause a crash, but the check has been moved from the array subscript to any subtraction on array indices.  As with divide-by-zero, it&#39;s the responsibility of the calling algorithm to make sure this never happens.</div><div><br></div><div>I think I&#39;m -1 on this.  Swift has for-each loops already that eliminate the vast majority of explicit array accesses.  For ones with a computed index, you&#39;d still need a check for &lt;0 on the computation.  Literal indices aren&#39;t much of a risk anyway - it&#39;s pretty obvious when you&#39;re subscripting with a literal negative number - but as others have pointed out, there are sometimes legit reasons why you might want a negative subscript or count property.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" dir="auto"><span class=""><div><blockquote type="cite"><div>On 3 Feb 2016, at 21:51, Jonathan Tang &lt;<a href="mailto:jonathan.d.tang@gmail.com" target="_blank">jonathan.d.tang@gmail.com</a>&gt; wrote:</div><br><div><div dir="ltr"><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">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><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&#39;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><br>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><br></blockquote><div><br></div><div>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&#39;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><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div></div></div></div></div></span></div></blockquote></div><br></div></div>