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

[Félix Cloutier]

It is not good enough for C interop because a design where the element count is data rather than part of the type cannot be layout-compatible with a C fixed-size array.

Félix

> Le 23 juil. 2017 à 22:22, Charles Srstka via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> Do FSAs really need special sugar, though? They won’t be an extremely heavily-used construct, but rather they’ll be occasionally used either for performance reasons or to interact with C APIs. Sure, C had a short syntax for making them, but making pointers in C was short, too, and that hasn’t been carried over into Swift. In fact, a FSA has a lot in common with an UnsafeBufferPointer that you don’t have to worry about deallocating. Furthermore, there are collection types such as Set and ContiguousArray which are arguably more useful than FSA, yet don’t have their own syntax.
> 
> Is this really not good enough?
> 
> let arr = FixedArray<Type>(capacity: x)
> 
> Charles
> 
>> On Jul 23, 2017, at 11:03 PM, Taylor Swift via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> This proposal gives FSAs their own literal syntax. You write [; 3, 5] to make a FSA, not [3, 5].
>> 
>> On Sun, Jul 23, 2017 at 11:54 PM, David Sweeris <davesweeris at mac.com <mailto:davesweeris at mac.com>> wrote:
>> 
>> On Jul 23, 2017, at 8:32 PM, Taylor Swift <kelvin13ma at gmail.com <mailto:kelvin13ma at gmail.com>> wrote:
>> 
>>> On Sun, Jul 23, 2017 at 5:48 PM, David Sweeris <davesweeris at mac.com <mailto:davesweeris at mac.com>> 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:
>>>> 
>>>>> 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. 
>> 
>> No, the type of the FSA's elements is what comes to the right: "[count * Type]". I don't recall any discussion around the value side of things, so I'd guess they would've just used the existing array literal syntax, "let fsa: [2*[2*Int]] = [[0, 1], [2, 3]]".
>> 
>> - Dave Sweeris
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170724/2659638f/attachment.html>