Well even if the behavioral subtyping might not fit for hundred percent in this scenario, my main point is that I don’t want Swift to contain exclusive features.
By that I mean that it’s far better to come up with something that has more potential and where the syntax could be reused for other *similar* purposes later on. Otherwise we’ll simply burn something now or create something that will not fit the future version of the language. For instances limited numeric types *might* look like this Double<0 … 1.0>, UInt8<0 … 4>. But this is only bike shedding and it has to be fleshed out in the future. On the other hand if you think about the big picture here, we’d might come up with a syntax for fixed-sized arrays which we’ll reuse later for instance for behavioral conditions. // again this is only some bikeshedding let fixed: [Int]<4> = [1, 2, 3, 4] // `<4>` at the end is omitted let fixed = [1, 2, 3, 4]<4> Type<…> is ambiguous Type[…] should be reserved for type subscripts […]Type might be reserved for property behaviors <…>Type might look odd with generic types, but could work Type(…) ambiguous but yet interesting in type context let arr1: Array<Int>(size: 3) = [1, 2, 3] let arr2: [Int](size: 3) = [1, 2, 3] let arr3 = Array<Int>(size: 3)() ambiguous I'd tend to some kind of type prefix syntax. let arr4: <3>[Int] = [1, 2, 3] let num1: <1.0 … 5.0>Double = … let arr5: <2>@[Int] = [1, 2] let num2: <0 … 1>@Double = … Obviously none of them are visually pleasant to my eyes. Am 23. Juli 2017 um 17:45:57, Taylor Swift (kelvin1...@gmail.com) schrieb: 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/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@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
