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

[Taylor Swift]

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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170803/2a32dd35/attachment.html>