<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 23, 2017 at 2:21 PM, David Sweeris <span dir="ltr">&lt;<a href="mailto:davesweeris@mac.com" target="_blank">davesweeris@mac.com</a>&gt;</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 dir="auto"><div><br></div><div><span class="gmail-">On Jul 23, 2017, at 09:08, Taylor Swift &lt;<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>&gt; wrote:<br><br></span><div><span class="gmail-"><blockquote type="cite"><div><div dir="ltr"><span class="gmail-m_-3186585211898980809gmail-im"><span style="font-family:monospace,monospace">let fsa:[2 * Int] = [2 * 5, 3</span><span style="font-family:monospace,monospace">] // [10, 3] ???</span></span></div></div></blockquote><div><br></div></span><div>Correct. If you wanted a multidimensional array, that&#39;d be written &quot;let nestedFSA: [2*[5*Int]]&quot;. Or, speculating a bit, I suppose maybe &quot;<span style="background-color:rgba(255,255,255,0)">let nestedFSA: [[5*Int]*2]&quot;, if we wanted there to be a column-major option</span>. IMHO all those read better than this proposal&#39;s syntax.</div></div><div><br></div><div><br></div></div></div></blockquote><div><br></div><div>No, what I’m saying is does the phrase “[2 * 5, 3]” mean a fixed size array of length two and with the elements 5 and 3, or a flexible sized array with two elements 10 and 3? This is v confusing and difficult to read, especially when you have actual multiplications going on such as <br><br></div><div><span class="gmail-"><div><div><span class="gmail-m_-3186585211898980809gmail-im"><span style="font-family:monospace,monospace">let fsa:[2 * Int] = [2 * 3 * 5, 3</span><span style="font-family:monospace,monospace">] // [15, 3] ???</span></span></div></div></span></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><span class="gmail-"><blockquote type="cite"><div><div dir="ltr">Using the <i>multiplication operator</i> as a <i>separator</i> character seems like an extraordinarily bad idea.</div></div></blockquote><div><br></div></span><div><span style="background-color:rgba(255,255,255,0)">Well, much to the dismay of my occasionally-inner Unicode fanboy, we decided that we didn&#39;t want to make everyone have to figure out how to type &quot;×&quot; to use a stdlib type (to the further dismay of my O-IUF, this is actually a really good argument, especially since a likely use for FSA is in embedded or systems programming, where you might need to use an editor that doesn&#39;t support Unicode).</span></div><div><br></div></div></blockquote><div><br></div><div>The text encoding of the source code shouldn’t have any effect on the compiled target? And while the ◊ or × suggestions are semi-rhetorical, given a choice between difficult-to-read syntax and unicode, I’ll choose unicode every time. Swift is nowhere near the first language to use unconventional symbols. Inserting special characters these days is barely harder than typing a capital letter. They should be used sparingly but not ruled out completely, and it doesn’t seem like there are many alternatives.<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 dir="auto"><div></div><div>I think another contender might&#39;ve been &quot;let fsa: [2 of Int]&quot;, but if you want a complete list, I&#39;ll have to go back and reread the quarter-dozen or so threads on FSAs that pop up whenever we lift the &quot;out of scope&quot; thing (but before they get ruled out of scope again). <span style="background-color:rgba(255,255,255,0)">Semantically speaking, &quot;count * MemoryLayout&lt;Type&gt;.stride&quot; is a pretty much exactly what we&#39;re doing at the storage level, so &quot;count * Type&quot; fits well in that regard (IMHO, anyway, since we want the syntax to be concise). It also works as syntactic sugar for declaring homogeneous tuples. <br></span></div></div></blockquote><div><br></div><div>If we’re actually going to try and establish a relationship between the FSA asterisk and the multiplication asterisk, this is even more problematic. How does the asterisk work in FSA literals, where there is no type annotation to go on the right of the asterisk? <br><br></div><div>Also introducing contextual keywords like “of” is going to cause a huge amount of problems with syntax highlighters considering how often the word “of” is used as an argument label in Swift. The words “as” and “stride” already make for some interesting code highlighting, “of” would take it to a whole new level.<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 dir="auto"><div><span style="background-color:rgba(255,255,255,0)"></span></div><div><br></div><div><span style="background-color:rgba(255,255,255,0)">Speaking of which, IIRC, at one point we were considering adding subscripts to tuples and using that for FSAs. I think the hangups were pretty much just that tuples can&#39;t conform to protocols and the iffy semantics of subscripting heterogeneous tuples. The former is a bit of a pain point anyway, and unless I&#39;ve forgotten about some deal-breaker that was brought up in one of those threads, I think it&#39;s somewhat likely that we&#39;ll eventually do something about it. Unrelated to FSAs and subscripting tuples, we&#39;ve also discussed variadic generic arguments... My recollection is that there was broad support for the idea; it&#39;s just a matter of it being in-scope so that we can figure out the syntax. Once we get that done, if we make tuples extendable we could just say (hand-wavey straw-man syntax, of course):</span></div><div><span style="background-color:rgba(255,255,255,0)">    extension (Ts: _...) where Ts.count &gt; 0, Ts.reduce(true) { $0 = Ts.Head.self == $1.self } == true {</span></div><div><div><span style="background-color:rgba(255,255,255,0)">        subscript(_ i: Int) -&gt; Ts.Head {...}</span></div><div><span style="background-color:rgba(255,255,255,0)">    }</span></div></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">... and just do it all through tuples. Is this a <i>better</i> than having a dedicated FSA type? Dunno. In large part, it depends on how difficult the various ideas will be to implement, and how useful the extra bits of functionality would be to the rest of the language. Unfortunately, the people who have those answers are busy working with the Swift 4.0 release, and likely don&#39;t have time to really weigh in on out of scope topics (which we all agree can be frustrating, but there are practical realities in life, and staying focused enough to meet deadlines is one of theirs).</span></div><div><br></div><div>- Dave Sweeris </div></div></blockquote><div><br></div><div>I don’t think tuples are a suitable replacement for FSAs. A tuple should be able to be broken up and optimized by the compiler, and have no contiguity guarantees in memory. <br></div></div><br></div></div>