I’m -1 on adding a fixed-sized Array type.
It goes back to something which I remember reading from John McCall earlier
this week but can’t find any more: about tuple indices being nominal and not
ordinal. How do fixed-size Arrays differ? Are their indexes truly not nominal?
The difference between a fixed-size array and the dynamically-sized Array we
already have is that the programmer expects specific data at each element.
Maybe it’s elements of a vector or matrix, or some other structure, but in
general I think that constraints about the size/shape of the sequence implies
expectations about what you’re going to find at each location. Maybe you would
normally write a struct for it, but it’s not worth writing out. In that sense,
how is it different from a homogenous tuple?
Also, what effect would this have on Array as the common-currency for simple
lists? And what about the literals - does [myObj, anotherObj] give you a
[MyObject] or a [2; MyObject]? Is that what users will intuitively expect? What
about if it’s a “let” constant?
So overall, I’m unconvinced of the need for fixed-size arrays. My
counter-proposal would be a shorthand syntax for more conveniently defining
homogenous tuples, and keep them as our go-to objects for ad-hoc groups of
things. That’s it. If you would have used a fixed-size Array in C, keep using
homogenous tuples in Swift.
As for the part about the @vector and @parallel attributes, those would be
worth a separate proposal. As for @parallel, I suggested something like that
before but Dave Abrahams said any such support would look more like a generic
concurrent wrapper, e.g.
https://gist.github.com/karwa/43ae838809cc68d317003f2885c71572
<https://gist.github.com/karwa/43ae838809cc68d317003f2885c71572>. Vector
support is worth thinking about in a separate proposal.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
