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

[Taylor Swift]

On Sun, Jul 23, 2017 at 2:21 PM, David Sweeris <davesweeris at mac.com> wrote:

>
> On Jul 23, 2017, at 09:08, Taylor Swift <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] ???


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

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.


>
> 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).
>
> - Dave Sweeris
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170723/df9931d9/attachment.html>