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

Daryle Walker darylew at mac.com
Wed Aug 2 23:45:06 CDT 2017

> On 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?

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.

> 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?

I’m not sure what you mean here. How do elements of dynamically-sized arrays not have expectations?

The big innovation arrays (and loops) brought was no longer having a per-sub-object declaration/command for elements. Just tweak a number.

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)?)

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?

Maybe there’s a copy of the FORTRAN design documents out there?...

> 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?

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.

> 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.

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.

Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170803/7e62c485/attachment.html>

More information about the swift-evolution mailing list