<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 23, 2017 at 5:48 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div dir="auto"><span class=""><div><br></div><div>On Jul 23, 2017, at 12:18, Taylor Swift &lt;<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><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="m_-7264807722288193896gmail-">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="m_-7264807722288193896gmail-"><blockquote type="cite"><div><div dir="ltr"><span class="m_-7264807722288193896gmail-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="m_-7264807722288193896gmail-"><div><div><span class="m_-7264807722288193896gmail-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></div></div></div></blockquote><div><br></div></span><div>That&#39;s... huh? To me, &quot;[<span style="background-color:rgba(255,255,255,0)">2 * 3 * 5, 3]&quot; should </span>obviously evaluate to &quot;[30, 3]&quot;. How are you getting that &quot;[2*5*3, 3]&quot; could be a 2-element FSA containing 15 and 3? Are you suggesting that instead of &quot;[value * value * value, value]&quot;, it could be parsed as &quot;[modifier value * value, value]&quot; (with `modifier` being &quot;2 *&quot;)? To me, that syntax would <i>strongly</i> suggest that the modifier only applies to the first element of the array, which would mean the only other option for parsing it would be equivalent to &quot;[[3, 5], 3]&quot;, which is neither a match for fsa&#39;s type, nor a semantically valid array (the elements have to be the same type), nor a syntactically valid array (the nested array in the first element is missing its &quot;[]&quot;).</div><span class=""><div><br></div></span></div></div></blockquote><div><br></div><div>Well, that <i>is</i> the syntax you’re proposing right? What comes on the left of the asterisk is the FSA dimensions, and what comes to the right is the FSA elements. So `2` is the FSA length, and `3 * 5` and `3` are the two elements in the FSA. Unless of course, the right-most asterisk is defined to be the separator, in which case our FSA has <i>six</i> elements, the first two of which are `5` and `3` (what if there was a `default:` argument?). This seems v confusing to me, since we now have asterisk-as-separator and asterisk-as-multiplication mixed together within the same brackets.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div dir="auto"><span class=""><div></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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="m_-7264807722288193896gmail-"><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></div></div></blockquote><div><br></div></span><div>I would choose the unicode route for my projects as well, but locking stdlib types or functionality behind unicode has been a no-go ever since Swift was open-sourced (and presumably before then as well, since nothing in the stdlib uses them). We couldn&#39;t even get the unicode operators for set notation: &quot;∩&quot;, &quot;∪&quot;, &quot;⊂&quot;, &quot;⊃&quot;, &quot;⊆&quot;, &quot;⊇&quot;, &quot;∈&quot;, &quot;∋&quot;, and &quot;∖&quot; (maybe not &quot;∖&quot;... it&#39;s been a while), accepted as <i>alternate</i> spellings for: &quot;setA.intersection(setB)&quot;, &quot;setA.union(setB)&quot;, etc, back in the &quot;Set Algebra&quot; proposal. I really doubt a proposal for FSAs with syntax involving unicode will be accepted. Feel free to try, though. Maybe there&#39;s been a change of heart since the topic last came up.</div><span class=""><div><br></div></span></div></div></blockquote><div><br></div><div>Unicode operators for set notation was a bad idea because there was a clear, readable non-unicode alternative available — the plain spelled-out methods. Here we are far more restricted in our options, so we may as well consider Unicode as a possible alternative.<br></div><div> </div></div><br></div></div>