[swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)

Thu Jan 28 23:41:35 CST 2016

I think that (4 x Int) needs to be syntax sugar for (Int, Int, Int, Int). Not having them the same would introduce awkward cases into the language.

Because of that, I also think that forcing people to use the subscript would have some awkward consequences. What if I have a func<T, U> that uses a (T, U) tuple and both T and U happen to be the same type?

So I think that tuples whose elements all have the same type should get a subscript but shouldn't lose direct field access. This would also avoid breaking existing code, and place the bounds check at compile-time instead of runtime. (The compiler will tell you if you try to access foo.4 on a (4 x Int) tuple, but it likely won't if you try to access foo[4]).

Félix

> Le 29 janv. 2016 à 00:18:43, Justin Kolb <justin.kolb at gmail.com> a écrit :
> 
> # Fixed Sized Arrays
> 
> * Proposal: TBD
> * Author(s): [Swift Developer](https://github.com/swiftdev <https://github.com/swiftdev>)
> * Status: **Awaiting review**
> * Review manager: TBD
> 
> ## Introduction
> 
> To provide better support for C static arrays and to help implement low level memory concious data structures, it would be helpful to add a new syntax to define fixed sized arrays of a single type in Swift.
> 
> Swift-evolution thread: [Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/007984.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/007984.html>)
> 
> ## Motivation
> 
> While Swift does allow for arrays and tuples with repeating instances of the same type, both do not map well to low level structures like C static arrays. It would be beneficial to provide a type with a closer mapping the the semantics and capabilities of C static arrays to help with interfacing with low level libraries and hardware (like GPU rendering data). While this can be accomplished in Swift currently it is awkward. Also most languages have some form of fixed size array and it's lacking in Swift has become more and more noticeable.
> 
> ## Proposed solution
> 
> It should be possible to take the current existing mapping from C static arrays to tuples and modify it slightly to help round out the feature. Changes to tuples would include a new syntax for defining fixed size arrays (shown below), adding subscripting to tuples, and providing a way to initialize this new form of tuple. To prevent confusion between standard tuples and fixed array tuples, only tuples that have no element labels and that have all the same element type would be allowed to be subscripted.
> 
> The syntax to declare a fixed size array would be as follows:
> 
>     var values: (4 x Int)
> 	
> The declaration would be surrounded by parenthesis similar to an existing tuple type, but the size of the array would be given first followed by the type of the elements of the array. The declaration given here would specify four consecutive Int values similar to the tuple `(Int, Int, Int, Int)`.
> 
> Initializing the individual elements of a fixed array would be similar to initialzing an existing tuple:
> 
>     let values: (4 x Int) = (1, 2, 3, 4)
> 
> Initializing all the elements to a single value would be done similar to calling an initializer on a type:
> 
>     let values: (4 x Int)(repeatedValue: 0) // Is this possible?
> 
> Instead of accessing individual elements of a tuple using index numbers such as `value.0` and `value.1` fixed size arrays will be indexed similar to normal arrays using normal subscript syntax `values[0]`.
> 
> ## Detailed design
> 
> TBD
> 
> ## Impact on existing code
> 
> As this would be a change in how static arrays from C are imported into Swift, any existing code using that feature would break due to the change in how to access the elements of the array. Applications making use of static C arrays would need to be recompiled and migrated to use newer syntax. If the decision is make to allow for both forms of indexing then no code would break due to this change and authors could migrate their code as needed to the new syntax.
> 
> ## Alternatives considered
> 
> Using tuples as they are implement now does provide access to C static arrays and to write data structures with memory layouts similar to C static arrays, but it is not a very elegant solution. If fixed arrays can be added to the language easily then it would be well worth it to improve Swift with the same functionality that is normally found in most system level languages.
> 
> 
>> On Jan 28, 2016, at 10:23 PM, Justin Kolb <justin.kolb at gmail.com <mailto:justin.kolb at gmail.com>> wrote:
>> 
>> I will make an attempt at a first draft given what I’ve read in this thread. I’m a little fuzzy on how to proceed as the process document makes mention of using the template and getting refinements on the mailing list before making a PR with the proposal. I have been having trouble finding examples of that in prior threads. Should I post the initial markdown to the thread?
>> 
>>> On Jan 28, 2016, at 9:57 PM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
>>> 
>>>> 
>>>> On Jan 28, 2016, at 5:07 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> I find 
>>>> 
>>>> let values: (4 x Int) = (1, 2, 3, 4)
>>>> 
>>>> to be adequately cromulent. I believe this approach to be:
>>>> 
>>>> * Readable, even to someone unfamiliar with the syntax
>>>> * The parens before the assignment suggest something to do with tuples, and the numbers match the arity after the assignment
>>>> * The type is preserved in-place
>>>> * It's compact, elegant, simple
>>> 
>>> +1.  I like this syntax too, and with Joe’s other proposed extensions, it would all fit together nicely.  Anyone interested in writing up a proposal?
>>> 
>>> -Chris
>>> 
>>> 
>>>> 
>>>> -- E
>>>> 
>>>> 
>>>>> On Jan 28, 2016, at 5:56 PM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>> 
>>>>>> On Jan 28, 2016, at 4:04 PM, Haravikk <e-mail at haravikk.me <mailto:e-mail at haravikk.me>> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On 28 Jan 2016, at 22:37, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>> On Jan 28, 2016, at 2:36 PM, Jacob Bandes-Storch <jtbandes at gmail.com <mailto:jtbandes at gmail.com>> wrote:
>>>>>>>> 
>>>>>>>> I like this idea, but the syntax seems dangerously close to a call site for  "func *(lhs: Int, rhs: Any.Type)"  (which is obviously ill-advised, but it is allowed).
>>>>>>>> 
>>>>>>>> Maybe we could take advantage of something which would be very invalid under the current grammar, namely (n T) rather than (n * T):
>>>>>>>> 
>>>>>>>>    let values: (4 Int) = (1, 2, 3, 4)
>>>>>>> 
>>>>>>> Sure, or we could lift (4 x Int) from LLVM IR's syntax.
>>>>>> 
>>>>>> How about:
>>>>>> 
>>>>>> 	let values:Int[4] = (1,2,3,4)
>>>>>> 
>>>>>> While it looks a bit like a subscript, it doesn’t make sense in a type declaration at present, so could be a good way to define restrictions of this type (we could even extend it to collections later). If the similarity is too close then:
>>>>>> 
>>>>>> 	let values:(Int[4]) = (1,2,3,4)
>>>>>> 
>>>>>> Could work too? Just some alternatives anyway, as I like the idea.
>>>>> 
>>>>> This kind of syntax doesn't compose well with other type productions. If you parse Int[N][M] naively as (Int[N])[M], then you end up with an array of M (array of N (Int)), which ends up subscripting in the opposite order, array[0..<M][0..<N]. C works around this by flipping the order of multiple array indices in a type declaration, so int [n][m] is really (int [m]) [n], but this doesn't work well for Swift, which has other postfix type productions—how would Int[N]?[M] parse? Choosing a prefix notation for fixed-sized array bounds is better IMO to avoid these pitfalls.
>>>>> 
>>>>> -Joe
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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/20160129/fdc514a6/attachment.html>