[swift-evolution] [Pitch] New Version of Array Proposal

[David Sweeris]

> On Jul 23, 2017, at 2:49 PM, David Sweeris via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> On Jul 23, 2017, at 12:18, Taylor Swift <kelvin13ma at gmail.com <mailto:kelvin13ma at gmail.com>> wrote:
> 
>> On Sun, Jul 23, 2017 at 2:21 PM, David Sweeris <davesweeris at mac.com <mailto:davesweeris at mac.com>> wrote:
>> 
>> On Jul 23, 2017, at 09:08, Taylor Swift <kelvin13ma at gmail.com <mailto:kelvin13ma at gmail.com>> wrote:
>> 
> 
>> 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):
>>     extension (Ts: _...) where Ts.count > 0, Ts.reduce(true) { $0 = Ts.Head.self == $1.self } == true {
>>         subscript(_ i: Int) -> Ts.Head {...}
>>     }
>> 
>> ... and just do it all through tuples. Is this a better 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).
>> 
>> 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.
> 
> 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.

To be clearer, I'm not claiming that we should 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 & 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 together for the direction Swift as a whole is going.

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 really 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?

- Dave Sweeris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170723/e5b4686c/attachment.html>