<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 23, 2017 at 5:29 AM, Adrian Zubarev via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div class="gmail-m_8204795069290857078bloop_markdown"><p>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.</p></div></div></blockquote><div><br></div><div>What about a double colon?<span style="font-family:monospace,monospace"><br></span><br><span style="font-family:monospace,monospace">let fsa:[5, 2::Int] = [5, 2::[::0, 0]: 5, [</span><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">::</span>5, 1]: 6, default: -1]<br><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div class="gmail-m_8204795069290857078bloop_markdown">
<p>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)?</p>
<p>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.</p>
<p></p></div><div class="gmail-m_8204795069290857078bloop_original_html"><div><div class="gmail-h5"><div id="gmail-m_8204795069290857078bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgb(0,0,0);margin:0px"><br></div></div></div></div></div></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div class="gmail-m_8204795069290857078bloop_original_html"><div><div class="gmail-h5"><div id="gmail-m_8204795069290857078bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgb(0,0,0);margin:0px"></div> <br> <div id="gmail-m_8204795069290857078bloop_sign_1500801385886533120" class="gmail-m_8204795069290857078bloop_sign"></div> <br><p class="gmail-m_8204795069290857078airmail_on">Am 22. Juli 2017 um 21:42:02, Daryle Walker via swift-evolution (<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>) schrieb:</p> </div></div><blockquote type="cite" class="gmail-m_8204795069290857078clean_bq"><span><div style="overflow-wrap: break-word;"><div></div><div><div><div class="gmail-h5">
<div>It’s at <<a href="https://gist.github.com/CTMacUser/cfffa526b971d0e1f3a079f53c6819bb" target="_blank">https://gist.github.com/<wbr>CTMacUser/<wbr>cfffa526b971d0e1f3a079f53c6819<wbr>bb</a>>.</div>
<div><br></div>
<div>* Try to clarify that fixed-size arrays are a new
kind of compound type, <b>not</b> a (ridiculously magical)
library generic type.</div>
<div>* Change the separator between the bounds and element
type from a colon to a semicolon.</div>
<div>* Specify that violating the bounds of an array
during indexing is a run-time error.</div>
<div>* Reword how the mapping of static-indexing elements
for multi-dimensional arrays works.</div>
<div>* 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.</div>
<div>* Move the “Reshaping Arrays” section and add an
example.</div>
<div>* 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.</div>
<div>* Remove the “parallel” declaration attribute. Add a
future note about it and the “fragmentary” attribute.</div>
<div>* Change the for-loop example to conform to
deterministic initialization. Reword how the flattening buffer
functions work.</div>
<div>* Add examples to element-wise casting.</div>
<div>* Reword tuple conversion section, and add an
example.</div>
<div>* 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.</div>
<div><br></div>
<div> let v1: @vector [3; Int] = [; 1, 3,
5]</div>
<div> let v2: [3; Int] = v1 // Not a
type-mismatch error</div>
<div><br></div>
<div>* 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.</div>
<div>* Renamed “nestings” to “layers”.</div>
<div><br></div>
<div>
<div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div>— </div>
<div>Daryle Walker<br>
Mac, Internet, and Video Game Junkie<br>
darylew AT mac DOT com </div>
</div>
</div>
<br></div></div><span class="gmail-">
______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></span></div></div></span></blockquote></div><div class="gmail-m_8204795069290857078bloop_markdown"><p></p></div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div>