[swift-evolution] [Pitch] New Version of Array Proposal

[Tino Heth]

> I’m not saying that tuple member names are “true integers” (although, with Reflection…). I understood that, semantically, the reason we refer to elements .0, .1 and .2 of a tuple because that’s their name, not necessarily because its their position in the tuple. My point is that for a fixed-size array like a [3; Double] vector, because you know what to expect at each location, those indices are *both* ordinal *and* nominal. Subscripting [0] or [1] from that FSA has the same conceptual meaning as accessing .x or .y on an equivalent struct. What I’m trying to say is: for a FSA, the index *is* the member name, just like the declaration-order number is for tuples.
I think one important aspect of an array is that the slots don't have a name at all...

> I think the difference is that, for a fixed-size Array, the absolute positions also generally have external meaning which is known to the programmer but not reflected in the type-system. For example, that a [3; Double] vector is supposed to be interpreted as (x, y, z) components, in that order.
> 
> We can do better than to expose a 3-element vector as a list of 3 unlabelled values. Or even a n-dimensional matrix just as a series of numbers.
I don't think we can — because a matrix is nothing but a bunch of numbers.
How would you name the elements in 600 × 2000 matrix?
Shorthands like x, y, z are only used in a very restricted environment that has little to do with real math.

> A better system may require meta-programming features we don’t support yet, and that’s fine, but I would really like us to focus on the actual use-cases of FSAs and to consider ways of making those great, rather than checking off a feature that we have to have ‘just because’.
As I said: I don't think there is a better system, but what features should that be?

> I remember that in the first Swift beta, you were allowed to mutate a “let” Array as long as you didn’t change its length. The community didn’t like it and things moved to COW instead.
… and it made a lot of sense, because "can't be resized" is not a very useful feature when you can't reason about the size, and "can't be modified at all" helps a lot.
Fixed-size arrays are completely different when they expose their size to the type checker.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170803/1aee711c/attachment.html>