<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 23, 2017, at 2:49 PM, David Sweeris via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div 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 &lt;<a href="mailto:kelvin13ma@gmail.com" class="">kelvin13ma@gmail.com</a>&gt; wrote:<br class=""><br class=""></div></div><div dir="auto" 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="">&nbsp; &nbsp; extension (Ts: _...) where Ts.count &gt; 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="">&nbsp; &nbsp; &nbsp; &nbsp; subscript(_ i: Int) -&gt; Ts.Head {...}</span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class="">&nbsp; &nbsp; }</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>&nbsp;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></div></blockquote><br class=""></div><div><div class="">To be clearer, I'm not claiming that we&nbsp;<i class="">should</i>&nbsp;implement FSAs as tuples, just pointing out that it might be a pretty easy option if certain other proposals were to be accepted. IMHO, it seems premature to put a ton of time &amp; effort into a FSA proposal now when there'll likely be a proposals for pretty much all the pieces required for the tuple-based approach as soon as these larger topics become in-scope. Even if we decide tuples aren't appropriate for FSAs (and again, I'm not arguing for or against that approach here), it seems likely to me that we'd want to design these features roughly together so that we can ensure that their syntaxes don't get in each others' ways and everything still feels right&nbsp;<i class="">together</i>&nbsp;for the direction Swift&nbsp;<i class="">as a whole</i>&nbsp;is going.</div><div class=""><br class=""></div><div class="">For example, the `ArrayStats` type in this proposal seems like it's mostly there as a work-around for Swift's current lack of Variadic Generics. Given that that's a feature we're likely to get at some point (hopefully in Swift 4.1 or 5, but we'll have to see what's in-scope), and that we don't want to support superfluous bits of code hanging around the stdlib or compiler (or language spec, since we're talking about a bunch of new grammar rules, too), and that we&nbsp;<i class="">really</i>&nbsp;don't want to break source compatibility later, doesn't it make sense to work on Variadic Generics first and see how that informs what we want to do WRT FSAs?</div><div class=""><br class=""></div><div class="">- Dave Sweeris</div></div><br class=""></body></html>