<div dir="ltr">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 <span style="font-family:monospace,monospace">switch case</span> is hideously verbose and introduces a lot of unnecessary branching.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 2, 2017 at 4:44 PM, Karl Wagner via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">I’m -1 on adding a fixed-sized Array type.<div><br></div><div>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?</div><div><br></div><div>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?</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>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. <a href="https://gist.github.com/karwa/43ae838809cc68d317003f2885c71572" target="_blank">https://gist.github.com/karwa/<wbr>43ae838809cc68d317003f2885c715<wbr>72</a>. Vector support is worth thinking about in a separate proposal.</div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>