FSA indices may be nominal, but you still need some way to store them. A good example of this is when you’re implementing cubemaps with 3-tuple vectors. Selecting a cube face involves selecting components of the vector at a variable offset supplied by a function parameter. Doing this with a switch case is hideously verbose and introduces a lot of unnecessary branching.
On Wed, Aug 2, 2017 at 4:44 PM, Karl Wagner via swift-evolution < swift-evolution@swift.org> wrote: > 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. 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 > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution