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

Adrian Zubarev adrian.zubarev at devandartist.com
Sun Jul 23 04:29:32 CDT 2017


I wanted to read the proposal, but skipped it as soon as I’ve seen the syntax. From the esthetic point of you the proposed syntax is really ugly. Again I’m not speaking against the feature in general, nor against any of the technical benefits fixed-size array will provide to us. I simply dislike the syntax, which in my opinion does not fit to Swift.

I think it might be better not pushing the fixed-size arrays here at all, but instead envision everything from a larger perspective. Wouldn’t be great to introduce value subtyping. Then enhance subtyping in general to allow static behavioral subtyping (also called type refinement)?

I’d love to see something like that happen to Swift. Arrays could have behavior subtypes which would allow fixed-size arrays. Numerical types could be bounded with ranges and provide a lot of compile time benefits.




Am 22. Juli 2017 um 21:42:02, Daryle Walker via swift-evolution (swift-evolution at swift.org) schrieb:

It’s at <https://gist.github.com/CTMacUser/cfffa526b971d0e1f3a079f53c6819bb>.

* 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/20170723/b7f1bf5e/attachment.html>


More information about the swift-evolution mailing list