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

[Taylor Swift]

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

>
> On Jul 23, 2017, at 12:18, Taylor Swift <kelvin13ma at gmail.com> wrote:
>
> 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] ???
>
>
> 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 "[]").
>
>
Well, that *is* the syntax you’re proposing right? What comes on the left
of the asterisk is the FSA dimensions, and what comes to the right is the
FSA elements. So `2` is the FSA length, and `3 * 5` and `3` are the two
elements in the FSA. Unless of course, the right-most asterisk is defined
to be the separator, in which case our FSA has *six* elements, the first
two of which are `5` and `3` (what if there was a `default:` argument?).
This seems v confusing to me, since we now have asterisk-as-separator and
asterisk-as-multiplication mixed together within the same brackets.


> 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.
>
>
Unicode operators for set notation was a bad idea because there was a
clear, readable non-unicode alternative available — the plain spelled-out
methods. Here we are far more restricted in our options, so we may as well
consider Unicode as a possible alternative.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170723/867fb901/attachment.html>