<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><br class=""></div><div class="">On Jul 23, 2017, at 12:18, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" class="">kelvin13ma@gmail.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Sun, Jul 23, 2017 at 2:21 PM, David Sweeris <span dir="ltr" class=""><<a href="mailto:davesweeris@mac.com" target="_blank" class="">davesweeris@mac.com</a>></span> wrote:<br class=""><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" class=""><div class=""><br class=""></div><div class=""><span class="gmail-">On Jul 23, 2017, at 09:08, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" target="_blank" class="">kelvin13ma@gmail.com</a>> wrote:<br class=""><br class=""></span><div class=""><span class="gmail-"><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><span class="gmail-m_-3186585211898980809gmail-im"><span style="font-family:monospace,monospace" class="">let fsa:[2 * Int] = [2 * 5, 3</span><span style="font-family:monospace,monospace" class="">] // [10, 3] ???</span></span></div></div></blockquote><div class=""><br class=""></div></span><div class="">Correct. If you wanted a multidimensional array, that'd be written "let nestedFSA: [2*[5*Int]]". Or, speculating a bit, I suppose maybe "<span style="background-color:rgba(255,255,255,0)" class="">let nestedFSA: [[5*Int]*2]", if we wanted there to be a column-major option</span>. IMHO all those read better than this proposal's syntax.</div></div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class=""><span class="gmail-"><div class=""><div class=""><span class="gmail-m_-3186585211898980809gmail-im"><span style="font-family:monospace,monospace" class="">let fsa:[2 * Int] = [2 * 3 * 5, 3</span><span style="font-family:monospace,monospace" class="">] // [15, 3] ???</span></span></div></div></span></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">That's... huh? To me, "[<span style="background-color: rgba(255, 255, 255, 0);" class="">2 * 3 * 5, 3]" should </span>obviously evaluate to "[30, 3]". How are you getting that "[2*5*3, 3]" could be a 2-element FSA containing 15 and 3? Are you suggesting that instead of "[value * value * value, value]", it could be parsed as "[modifier value * value, value]" (with `modifier` being "2 *")? To me, that syntax would <i class="">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 "[[3, 5], 3]", which is neither a match for fsa'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 "[]").</div><div class=""><br class=""></div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><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" class=""><span class="gmail-"><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">Using the <i class="">multiplication operator</i> as a <i class="">separator</i> character seems like an extraordinarily bad idea.</div></div></blockquote><div class=""><br class=""></div></span><div class=""><span style="background-color:rgba(255,255,255,0)" class="">Well, much to the dismay of my occasionally-inner Unicode fanboy, we decided that we didn't want to make everyone have to figure out how to type "×" 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't support Unicode).</span></div><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">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 class=""></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">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't even get the unicode operators for set notation: "∩", "∪", "⊂", "⊃", "⊆", "⊇", "∈", "∋", and "∖" (maybe not "∖"... it's been a while), accepted as <i class="">alternate</i> spellings for: "setA.intersection(setB)", "setA.union(setB)", etc, back in the "Set Algebra" proposal. I really doubt a proposal for FSAs with syntax involving unicode will be accepted. Feel free to try, though. Maybe there's been a change of heart since the topic last came up.</div><div class=""><br class=""></div><div class=""> </div><blockquote type="cite" class=""><div dir="ltr" class=""><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" class=""><div class=""></div><div class="">I think another contender might've been "let fsa: [2 of Int]", but if you want a complete list, I'll have to go back and reread the quarter-dozen or so threads on FSAs that pop up whenever we lift the "out of scope" thing (but before they get ruled out of scope again). <span style="background-color:rgba(255,255,255,0)" class="">Semantically speaking, "count * MemoryLayout<Type>.stride" is a pretty much exactly what we're doing at the storage level, so "count * Type" 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 class=""></span></div></div></blockquote><div class=""><br class=""></div><div class="">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 class=""></div></div></div></div></blockquote><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Is there a reason the existing type inference system wouldn't work?</div><div dir="auto" class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">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 class=""></div></div></div></div></blockquote><div dir="auto" class=""><br class=""></div>I'm not sure we should be basing decisions like this on potential bugs in the syntax highlighting systems of various IDEs.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class=""><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><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" class=""><div class=""><span style="background-color:rgba(255,255,255,0)" class="">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'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've forgotten about some deal-breaker that was brought up in one of those threads, I think it's somewhat likely that we'll eventually do something about it. Unrelated to FSAs and subscripting tuples, we've also discussed variadic generic arguments... My recollection is that there was broad support for the idea; it'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 class=""><span style="background-color:rgba(255,255,255,0)" class=""> extension (Ts: _...) where Ts.count > 0, Ts.reduce(true) { $0 = Ts.Head.self == $1.self } == true {</span></div><div class=""><div class=""><span style="background-color:rgba(255,255,255,0)" class=""> subscript(_ i: Int) -> Ts.Head {...}</span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class=""> }</span></div></div><div class=""><span style="background-color:rgba(255,255,255,0)" class=""><br class=""></span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class="">... and just do it all through tuples. Is this a <i class="">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'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 class=""><br class=""></div></div></blockquote><div class="">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.</div></div></div></div>
</blockquote><br class=""></div><div dir="auto" class="">C's static arrays are imported as tuples, which need at least some level of contiguity guarantees to work. Even if tuples in general make that such a guarantee, tuple-based FSAs could use the same compiler logic as imported C arrays.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">- Dave Sweeris</div></body></html>