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

[Jonathan Tang]

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/a45d5fc7/attachment.html>