[swift-evolution] [Pitch] New Version of Array Proposal
razielim at gmail.com
Wed Aug 2 15:44:29 CDT 2017
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution