<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>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.</p>
<p>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.</p>
<p>For instances limited numeric types *might* look like this <code>Double<0 … 1.0></code>, <code>UInt8<0 … 4></code>.</p>
<p>But this is only bike shedding and it has to be fleshed out in the future.</p>
<p>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.</p>
<pre><code>// 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>
</code></pre>
<pre><code>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 = …
</code></pre>
<p>Obviously none of them are visually pleasant to my eyes.</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_1500827112504920832" class="bloop_sign"></div> <br><p class="airmail_on">Am 23. Juli 2017 um 17:45:57, Taylor Swift (<a href="mailto:kelvin13ma@gmail.com">kelvin13ma@gmail.com</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>
<title></title>
<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>
</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">
<div style="overflow-wrap: break-word;">
<div>
<div>
<div class="gmail-h5">
<div><span>It’s at <<a href="https://gist.github.com/CTMacUser/cfffa526b971d0e1f3a079f53c6819bb" target="_blank">https://gist.github.com/<wbr>CTMacUser/<wbr>cfffa526b971d0e1f3a079f53c6819<wbr>bb</a>>.</span></div>
<div><span><br></span></div>
<div><span>* Try to clarify that fixed-size arrays are a new kind
of compound type, <b>not</b> a (ridiculously magical) library
generic type.</span></div>
<div><span>* Change the separator between the bounds and element
type from a colon to a semicolon.</span></div>
<div><span>* Specify that violating the bounds of an array during
indexing is a run-time error.</span></div>
<div><span>* Reword how the mapping of static-indexing elements for
multi-dimensional arrays works.</span></div>
<div><span>* 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.</span></div>
<div><span>* Move the “Reshaping Arrays” section and add an
example.</span></div>
<div><span>* 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.</span></div>
<div><span>* Remove the “parallel” declaration attribute. Add a
future note about it and the “fragmentary” attribute.</span></div>
<div><span>* Change the for-loop example to conform to
deterministic initialization. Reword how the flattening buffer
functions work.</span></div>
<div><span>* Add examples to element-wise casting.</span></div>
<div><span>* Reword tuple conversion section, and add an
example.</span></div>
<div><span>* 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.</span></div>
<div><span><br></span></div>
<div><span> let v1: @vector [3; Int] = [; 1, 3,
5]</span></div>
<div><span> let v2: [3; Int] = v1 // Not a
type-mismatch error</span></div>
<div><span><br></span></div>
<div><span>* 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.</span></div>
<div><span>* Renamed “nestings” to “layers”.</span></div>
<div><span><br></span></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><span>— </span></div>
<div><span>Daryle Walker<br>
Mac, Internet, and Video Game Junkie<br>
darylew AT mac DOT com </span></div>
</div>
</div>
<span><br></span></div>
</div>
<span><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></span></div>
</div>
</blockquote>
</div>
<div class="gmail-m_8204795069290857078bloop_markdown"></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>
</div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>