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

[Taylor Swift]

Hi, I’ve been watching this proposal for a while but didn’t get to read it
in detail until now. I really like this idea and it’s very comprehensive
and well-thought out. Some feedback:

1. I got very confused reading through the document the first time through.
You’re introducing a huge amount of new syntax and jargon, and not defining
all of them before first using it. For example, what does `a[[;3]]` and `b[[;1,
4]]` after the seventh paragraph mean? This bounds-omission syntax isn’t
explained until the Array Values section, and it’s buried in the middle of
a paragraph.

2. Using the semicolon as the bounds separator feels a bit weird,
especially when combined with the colons in the initializers. In English,
semicolons bind closer than colons do, so `[13, 2; [;0, 0]: 0, [;0, 1]: 0,
default: -1]` reads strangely. Also, where does the type annotation go?
Having a semicolon after a left square bracket “[;” also makes for ugly code
texture <http://elm-lang.org/blog/compilers-as-assistants>, something to
think about considering I’m going to be staring at *a lot* of these things.
Then again, I’m struggling to think up an alternative syntax.

3. Some of the syntax rules could benefit from providing a little
explanation, as the rationale is not always immediately obvious, for
example:

- Allowing a single number for the left side of the dictionary literal
pair, but not a comma-separated index list.

[5, 2; 2, 1: 5]

of course, the comma character is already reserved for separating
key-element pairs, but I had to think for a while before realizing that.

- `func` not being allowed to coexist with other initialization pairs. My
first thought was “why can’t `func:`initialize all the elements that
weren’t covered by anything else, like `default:` does? I guess this is to
ensure an efficient implementation of the closure initializer, but again,
this is non-obvious.

4. Please define terms like  “term”, “array-index term” and “single-number
term” and “index set”, among others, preferably in boldface at the top of
the document. This proposal is hard enough to follow without having to
puzzle out what an “array-index term” is. (Isn’t *every* index an array
index term?)

5. There’s a lot of awkward and confusing language that I had to go back
and reread many times over to figure out what it meant. Examples: “*The
number to the left of the colon is the index of the element to receive the
value on the right of the colon.*” (what???), “*with an explicit bound
(set)*” (first thought: Why is “set” in parentheses? Does it not matter
whether you set an explicit bound?). Again, this proposal is hard enough to
follow without having to puzzle out that “(set)” refers to a list of
multiple indices, not *setting* a single index.

6. “*The element type of the array is determined by either the return type
of a function term's closure, or by the type consolidated from all the term
values (like in dictionary and standard-array literals).*” That second part
is going to kill the type checker, since I’m guessing in practice FSAs are
going to have much longer literals than flexible arrays or dictionaries do
right now.

7. You should add a section in the FAQ justifying the use of `as` for FSA
shape conversion. Why not initializer syntax?

let d = [4, 3; 1, 2, 3, default: 0]let e = [4, 3; Double](d)

I agree that `as` is better than magical initializers, but there are
legitimate arguments against `as` too. Right now, `as` is reserved for
literals and class types. Applying an `as` cast to a value type is an
entirely new use-context for the keyword.

8. What is a “sub-object”??? This word started randomly appearing halfway
through the document with no definition.

9. I don’t see the value in having both nested FSAs and multi-dimensional
FSAs. Aren’t they the same thing? For example, in the code snippet

```
let a = [;1, 2, 3, 4]
assert(a[0] == 1)
assert(a[1] == 2)
assert(a[2] == 3)
assert(a[3] == 4)
let b = a as [2, 2; Int]
assert(b[0, 0] == 1)
assert(b[0, 1] == 2)
assert(b[1, 0] == 3)
assert(b[1, 1] == 4)
let c = a as [2; [2; Int]]
assert(c[0][0] == 1)
assert(c[0][1] == 2)
assert(c[1][0] == 3)
assert(c[1][1] == 4)
```

There’s three syntaxes which accomplish two unique things. I lean towards
disallowing FSA nesting and instead allowing *incomplete* index lists to
partially unnest multidimensional FSAs. Let’s reserve “[][][]...” for
flexible array chained dereferencing.

10. I don’t see much value in runtime DI. It seems to add a lot of
complexity to the compiler with little benefit.

11. This should have defined behavior:

let data = [2, 2; 1, 2, 4, 8]
for (i, x) in data.enumerated()
{
    total += x
}

“with” methods should be used sparingly and not be part of common idioms
like iterating through an array as a buffer.

12. Can we rename the `cardinality` type property to `nestingCount` or
`nestingLevels` something similar? That seems a lot clearer and more
descriptive of that the property actually represents. I’d also bet that
close to no one knows what cardinality is.

On Sat, Jul 22, 2017 at 3:41 PM, Daryle Walker via swift-evolution <
swift-evolution at swift.org> wrote:

> It’s at <https://gist.github.com/CTMacUser/cfffa526b971d0e1f3a079f53c6819
> bb>.
>
> * Try to clarify that fixed-size arrays are a new kind of compound type,
> *not* a (ridiculously magical) library generic type.
> * Change the separator between the bounds and element type from a colon to
> a semicolon.
> * Specify that violating the bounds of an array during indexing is a
> run-time error.
> * Reword how the mapping of static-indexing elements for multi-dimensional
> arrays works.
> * Completely redo array values/literals. A literal for a fixed-size array
> always includes a semicolon, which separates the bounds from the values.
> (The separator in FSA types was changed to a semicolon to match.) A value
> can be a plain expression or a dictionary expression where the right side
> of the colon is the value and the left side is the index of the target
> element or “default” for all un-targeted elements. The left side can also
> be “func”, with the right side being an initialization closure.
> * Move the “Reshaping Arrays” section and add an example.
> * Right now, deterministic initialization is unchanged, so an initializing
> loop has to be changed to initializing the array with a function term,
> moving the loop to the closure.
> * Remove the “parallel” declaration attribute. Add a future note about it
> and the “fragmentary” attribute.
> * Change the for-loop example to conform to deterministic initialization.
> Reword how the flattening buffer functions work.
> * Add examples to element-wise casting.
> * Reword tuple conversion section, and add an example.
> * Reword various vector-mode attribute sections. Note that there need to
> be two ABI additions for FSA, one for non-vectorized FSAs and one for
> vectorized FSAs. These two kinds of arrays need conversion functions at our
> (i.e. the ABI) level, but are transparent for the user.
>
>     let v1: @vector [3; Int] = [; 1, 3, 5]
>     let v2: [3; Int] = v1  // Not a type-mismatch error
>
> * Due to FSA’s literals including the bounds, or using automatic bounds
> mode, array-placeholder syntax is not longer needed for type annotations
> and has been removed.
> * Renamed “nestings” to “layers”.
>
> —
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com
>
>
> _______________________________________________
> 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/20170722/d52382bd/attachment.html>