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

[David Sweeris]

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:
> 
>> let fsa:[2 * Int] = [2 * 5, 3] // [10, 3] ???
> 
> Correct. If you wanted a multidimensional array, that'd be written "let nestedFSA: [2*[5*Int]]". Or, speculating a bit, I suppose maybe "let nestedFSA: [[5*Int]*2]", if we wanted there to be a column-major option. IMHO all those read better than this proposal's syntax.
> 
> 
> 
> 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 
> 
> let fsa:[2 * Int] = [2 * 3 * 5, 3] // [15, 3] ???

That's... huh? To me, "[2 * 3 * 5, 3]" should 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 strongly 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 "[]").


>> Using the multiplication operator as a separator character seems like an extraordinarily bad idea.
> 
> 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).
> 
> 
> 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.

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 alternate 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.

 
> 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). 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. 
> 
> 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?

Is there a reason the existing type inference system wouldn't work?


> 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.

I'm not sure we should be basing decisions like this on potential bugs in the syntax highlighting systems of various IDEs.


> 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.


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