On Sun, Jul 23, 2017 at 5:29 AM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote:
> 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. > What about a double colon? let fsa:[5, 2::Int] = [5, 2::[::0, 0]: 5, [::5, 1]: 6, default: -1] 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. > > > This sounds like a recipe for never making fixed size arrays happen at all. I’d rather actually get the base feature (contiguous variables) in first, then worry about static behavioral subtyping later. > > > Am 22. Juli 2017 um 21:42:02, Daryle Walker via swift-evolution ( > swift-evolution@swift.org) schrieb: > > 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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution