<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Aug 2, 2017, at 4:44 PM, Karl Wagner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I’m -1 on adding a fixed-sized Array type.<div class=""><br class=""></div><div class="">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></div></blockquote><div><br class=""></div><div>I think he meant that the numbered names for tuple members were originally (?) there because the Swift authors didn’t mandate each member needing a label, so there needed some way to refer to unnamed members. Note that numbered names are not true integer variables, not even useable as such. Array indexes are programmable objects; algorithms on the indexes is how we select array subsets to apply algorithms on.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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></div></blockquote><div><br class=""></div><div>I’m not sure what you mean here. How do elements of dynamically-sized arrays not have expectations?</div><div><br class=""></div><div>The big innovation arrays (and loops) brought was no longer having a per-sub-object declaration/command for elements. Just tweak a number.</div><div><br class=""></div><div>I’m not good at explicit explanations, so having to justify adding a type that’s been around for a long time (at least FORTRAN 4+ decades ago) an almost every systems programming language has is frustrating. I thought the desire would be obvious; if there were FSAs in Swift 1, would there be any “just slap Collection on tuples and be done with it” suggestions now? It doesn’t help that I still don’t know why FSAs where skipped in Swift 1; did they forget or was there some high-level type-theory reason? (Were the type description records in the Swift ABI too fragile for a type that wouldn’t have per-sub-object entries (assuming theoretical Swift-1-FSAs weren’t translated to massive homogenous tuples)?)</div><div><br class=""></div><div>I mentioned in my proposal that no language (that I know of) splatted tuple and array syntax together, either declaration syntax or dereferencing syntax. (Lua has shared dereferencing syntax, but they both rip-off dictionaries.) Where do people think every one else over the last few decades went wrong?</div><div><br class=""></div><div>Maybe there’s a copy of the FORTRAN design documents out there?...</div><div><br class=""></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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></blockquote><div><br class=""></div><div>Later revisions of the proposal have a distinct grid literal syntax, to clear up any potential confusion. The standard array literals would map to Array. The grid literal, which includes the dimensions of the array before a list of each value, would map to a fixed-size array.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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 class=""><br class=""></div><div class="">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" class="">https://gist.github.com/karwa/43ae838809cc68d317003f2885c71572</a>. Vector support is worth thinking about in a separate proposal.</div></div></div></blockquote><br class=""></div><div>A main point for my FSA design is that I want to allow the default iteration primitive (for-loop) to have a vectorized/parallel implementation (someday). Since Sequence/Collection always has a sequential traversal policy (It’s in the name!), it’s the main reason FSA don’t directly conform to Collection in the design.</div><div><br class=""></div><div class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">— </div><div class="">Daryle Walker<br class="">Mac, Internet, and Video Game Junkie<br class="">darylew AT mac DOT com </div></div></div><br class=""><div><blockquote type="cite" class=""></blockquote></div></div></body></html>