<html><head><style>
body {
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
padding:1em;
margin:auto;
background:#fefefe;
}
h1, h2, h3, h4, h5, h6 {
font-weight: bold;
}
h1 {
color: #000000;
font-size: 28pt;
}
h2 {
border-bottom: 1px solid #CCCCCC;
color: #000000;
font-size: 24px;
}
h3 {
font-size: 18px;
}
h4 {
font-size: 16px;
}
h5 {
font-size: 14px;
}
h6 {
color: #777777;
background-color: inherit;
font-size: 14px;
}
hr {
height: 0.2em;
border: 0;
color: #CCCCCC;
background-color: #CCCCCC;
display: inherit;
}
p, blockquote, ul, ol, dl, li, table, pre {
margin: 15px 0;
}
a, a:visited {
color: #4183C4;
background-color: inherit;
text-decoration: none;
}
#message {
border-radius: 6px;
border: 1px solid #ccc;
display:block;
width:100%;
height:60px;
margin:6px 0px;
}
button, #ws {
font-size: 12 pt;
padding: 4px 6px;
border-radius: 5px;
border: 1px solid #bbb;
background-color: #eee;
}
code, pre, #ws, #message {
font-family: Monaco;
font-size: 10pt;
border-radius: 3px;
background-color: #F8F8F8;
color: inherit;
}
code {
border: 1px solid #EAEAEA;
margin: 0 2px;
padding: 0 5px;
}
pre {
border: 1px solid #CCCCCC;
overflow: auto;
padding: 4px 8px;
}
pre > code {
border: 0;
margin: 0;
padding: 0;
}
#ws { background-color: #f8f8f8; }
.bloop_markdown table {
border-collapse: collapse;
font-family: Helvetica, arial, freesans, clean, sans-serif;
color: rgb(51, 51, 51);
font-size: 15px; line-height: 25px;
padding: 0; }
.bloop_markdown table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0; }
.bloop_markdown table tr:nth-child(2n) {
background-color: #f8f8f8; }
.bloop_markdown table tr th {
font-weight: bold;
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr td {
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr th :first-child, table tr td :first-child {
margin-top: 0; }
.bloop_markdown table tr th :last-child, table tr td :last-child {
margin-bottom: 0; }
.bloop_markdown blockquote{
border-left: 4px solid #dddddd;
padding: 0 15px;
color: #777777; }
blockquote > :first-child {
margin-top: 0; }
blockquote > :last-child {
margin-bottom: 0; }
code, pre, #ws, #message {
word-break: normal;
word-wrap: normal;
}
hr {
display: inherit;
}
.bloop_markdown :first-child {
-webkit-margin-before: 0;
}
code, pre, #ws, #message {
font-family: Menlo, Consolas, Liberation Mono, Courier, monospace;
}
.send { color:#77bb77; }
.server { color:#7799bb; }
.error { color:#AA0000; }</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="bloop_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>
<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="bloop_original_html"><style>body{font-family:Helvetica,Arial;font-size:13px}</style><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br> <div id="bloop_sign_1500801385886533120" class="bloop_sign"></div> <br><p class="airmail_on">Am 22. Juli 2017 um 21:42:02, Daryle Walker via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div></div><div>
<title></title>
<div class="">It’s at <<a href="https://gist.github.com/CTMacUser/cfffa526b971d0e1f3a079f53c6819bb" class="">https://gist.github.com/CTMacUser/cfffa526b971d0e1f3a079f53c6819bb</a>>.</div>
<div class=""><br class=""></div>
<div class="">* Try to clarify that fixed-size arrays are a new
kind of compound type, <b class="">not</b> a (ridiculously magical)
library generic type.</div>
<div class="">* Change the separator between the bounds and element
type from a colon to a semicolon.</div>
<div class="">* Specify that violating the bounds of an array
during indexing is a run-time error.</div>
<div class="">* Reword how the mapping of static-indexing elements
for multi-dimensional arrays works.</div>
<div class="">* 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 class="">* Move the “Reshaping Arrays” section and add an
example.</div>
<div class="">* 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 class="">* Remove the “parallel” declaration attribute. Add a
future note about it and the “fragmentary” attribute.</div>
<div class="">* Change the for-loop example to conform to
deterministic initialization. Reword how the flattening buffer
functions work.</div>
<div class="">* Add examples to element-wise casting.</div>
<div class="">* Reword tuple conversion section, and add an
example.</div>
<div class="">* 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 class=""><br class=""></div>
<div class=""> let v1: @vector [3; Int] = [; 1, 3,
5]</div>
<div class=""> let v2: [3; Int] = v1 // Not a
type-mismatch error</div>
<div class=""><br class=""></div>
<div class="">* 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 class="">* Renamed “nestings” to “layers”.</div>
<div class=""><br class=""></div>
<div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">— </div>
<div class="">Daryle Walker<br class="">
Mac, Internet, and Video Game Junkie<br class="">
darylew AT mac DOT com </div>
</div>
</div>
<br class="">
_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>