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

James Froggatt conductator at ntlworld.com
Thu Feb 4 05:48:17 CST 2016


> On 4 Feb 2016, at 01:08, David Turnbull <dturnbull at gmail.com> wrote:
> 
> Here's how you could use a collection as a predicate. The OnSwitchesIndex is opaque to anything outside the file. There's no way to iterate OnSwitches with  0 ..<count. Thinking that arrays and sequences are counting up from 0 by 1 is missing the entire point of these protocols.


No matter the index, since .count represents the number of elements in the collection, it should never be negative.

An EveryOtherElementOfReverseOfArray implementation could have a startIndex of 4 and endIndex of 0, and wouldn't be iterable with a simple range, yet I'd still expect the count to be positive. Types without integer indexes are no exception.


For cases such as CGSize: from memory, I have no idea how CGSize would handle negatives. Would it ignore the sign, crash on creation, or simply allow them?


According to the CGGeometry reference:

A CGSize structure is sometimes used to represent a distance vector, rather than a physical size. As a vector, its values can be negative. To normalize a CGRect structure so that its size is represented by positive values, call the CGRectStandardize function.


CGSize represents vectors and sizes? And an explicit ‘normalisation’ (a non-negative safety check) must be performed to work with CGSize as a size? This sounds awfully like a lack of type safety.

So based on CGSize's use as a vector, it would have to remain unchanged. Using naturals elsewhere in the frameworks would serve to make it much more obvious negative checks should be performed working with this and similar types. This example just serves to emphasise how important making this distinction is.

From James F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160204/fa343596/attachment.html>


More information about the swift-evolution mailing list