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

[David Turnbull]

-1  CollectionType and it's ilk, contrary to what you believe, were
designed to handle negative indexes just fine. Or even indexes that aren't
numeric. And there's plenty of real use cases for this.

class GraphRow : MutableCollectionType {

    var values = [Int](count: 201, repeatedValue: 0)

    var startIndex: Int { return -100 }

    var endIndex: Int { return 100 }

    subscript(column: Int) -> Int {

        get {

            return values[column+100]

        }

        set {

            values[column+100] = newValue

        }

    }

}

var r = GraphRow()

r[-3] = 12

r[9] = 2

print(r[-3])

print(r.reduce(0, combine: +))

-david


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.
>
> If this change were accepted, the user would have to explicitly convert
> between the types at some points in their code. This could be seen as a
> burden, but requiring a cast encourages the programmer to check for
> negative values, keeping negatives out of natural number functions, and
> moving checks to the source of the data, similar to how Optionals eliminate
> nil values early on.
>
> The parallel to Optionals is, in my opinion, the most appealing aspect of
> this idea. With Swift's focus on type safety, the lack of distinction
> between natural numbers and potentially negative ones seems like an
> omission, given how commonly both kinds of number are used. Enabling this
> level of integral safety would add additional clarity and reduce potential
> errors. Use cases include not just indexes, but in sizes such as
> collections' count and CG dimensions, for both clarity when getting values,
> and enforcing valid values at initialisation.
>
> UInt is the obvious candidate to represent integer natural numbers, but is
> hazardous in edge cases: UInt allows an extra bit for magnitude, so has the
> possibility of overflow when converting back to Int. I assume this hazard
> is the primary reason UInt currently isn't used. If this a concern, a
> separate collection of types for natural integers (NInt?) could be created,
> which could be a strict subset of the correspondingly sized Int values
> (using n-1 bits).
>
> This would mean adding a new collection of integer types in the standard
> library, which is undesirable. However, for high level applications which
> Swift is primarily used for, this would arguably be a more useful type than
> UInt, considering the near absence of UInt in current APIs, and its tiny
> increase (1 bit?) in precision compared to using an Int of a larger size.
> An unsigned Integer subset would allow safe conversion back to Int, and the
> conversion from Int is relatively simple, from the design perspective -
> ignore the sign bit, throw an error, or round up to 0, as appropriate.
>
> Alternatives include:
> • A generic wrapper for Int which constrains its possible values. This
> would allow inherent support for use with existing operators, but would be
> rather clunky in cases where only natural numbers are being dealt with.
> • In a future version of Swift, the addition of type parameters
> constraining possible values may enable this to be added, but even if this
> does get added it may be too late to make such a major change.
> • Leaving the APIs as they are and require every function dealing with
> natural numbers to either throw a runtime error when a negative is passed.
> If the user forgets to follow this rule (or wont put in the extra effort to
> add the check), their functions will have unspecified behaviour.
>
> This ended up longer than I would like, sorry about that. I don't think
> this issue has been covered here.
> I'd be interested to hear responses and opinions, and while I'm confident
> this change would be beneficial if done correctly, doing it correctly is
> easier said that done.
>
> - James
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160203/09de0a42/attachment.html>