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

Mon Jul 24 11:22:34 CDT 2017

There are other alternatives that don't use generics. Last time this came around, the straw man syntax was (4 x Int), and it was merely to be a shorthand for (Int, Int, Int, Int).

Every non-existing feature that needs to be implemented to make fixed-size arrays work are a drag. I've said it before and I'll say it again: major features that this proposal wants to rely on should be brought independently and discussed on their own. There are real problems with monolithic proposals:

They couple independent features in an all-or-nothing basket
They consume a huge amount of review and design energy
They force sub-features to be viewed through the telescope aimed at the main feature, and make it easier to miss problems or opportunities in the big pictures

The last point is especially worrying to me because things like non-type generic parameters are *much bigger* than fixed-size arrays. I think that it's a priority inversion to discuss non-type generic parameters as a bullet point of fixed-size arrays.

Félix

> Le 24 juil. 2017 à 01:37, David Sweeris <davesweeris at mac.com> a écrit :
> 
> Which brings us I think full circle back to using literal values as generic parameters, "let fsa = FSA<Type, Count>(whateverArgs) //where `Count` is an integer literal, or some other integer value that can be determined at compile time".
> 
> - Dave Sweeris
> 
> On Jul 24, 2017, at 1:05 AM, Félix Cloutier via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> 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 <mailto: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 <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <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/2c82c163/attachment.html>