[swift-evolution] Representation of natural numbers with a distinct type

[James Froggatt]

Fair point, though I'll point out that if the subtraction of Array indices ever did result in a negative, using the result as an index will result in a runtime error already.

If the negative result is useful, an explicit cast would be necessary for both operands. The main issue with this idea does seem to be the explicit casting, and this would have to be either accepted, or else overcome to make working with naturals more friendly, for this proposal to be accepted.

One solution would be an operator like subtract which returns an Int, to allow for easy conversion in this case, however this smells of a workaround.

Even if the idea isn't accepted, any solution we find for the problem of working with naturals would be equally applicable to UInt, so the discussion seems worth having either way.

From James F

> On 3 Feb 2016, at 22:26, Jonathan Tang <jonathan.d.tang at gmail.com> wrote:
> 
> 
>> On Wed, Feb 3, 2016 at 2:17 PM, James Samuel Froggatt <conductator at ntlworld.com> wrote:
>> That is an interesting point. Based on how the operators are defined for Int:
>> 
>> ‘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 a &+ b)’
>> https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/BasicOperators.html
>> 
>> 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.
>> 
>> 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.
> 
> We'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's the responsibility of the calling algorithm to make sure this never happens.
> 
> I think I'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'd still need a check for <0 on the computation.  Literal indices aren't much of a risk anyway - it's pretty obvious when you'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.
>  
>>> On 3 Feb 2016, at 21:51, Jonathan Tang <jonathan.d.tang at gmail.com> wrote:
>>> 
>>>> On Wed, Feb 3, 2016 at 9:31 AM, James Froggatt via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 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.
>>>> 
>>>> 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.
>>> 
>>> 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.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160203/57f1b9f7/attachment.html>