[swift-evolution] [Pitch] New Version of Array Proposal
Taylor Swift
kelvin13ma at gmail.com
Sun Jul 23 10:45:54 CDT 2017
On Sun, Jul 23, 2017 at 5:29 AM, Adrian Zubarev via swift-evolution <
swift-evolution at 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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> 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/01c0998b/attachment.html>
More information about the swift-evolution
mailing list