<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""># Fixed Sized Arrays</div><div class=""><br class=""></div><div class="">* Proposal: TBD</div><div class="">* Author(s): [Swift Developer](<a href="https://github.com/swiftdev" class="">https://github.com/swiftdev</a>)</div><div class="">* Status: **Awaiting review**</div><div class="">* Review manager: TBD</div><div class=""><br class=""></div><div class="">## Introduction</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Swift-evolution thread: [Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)](<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/007984.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/007984.html</a>)</div><div class=""><br class=""></div><div class="">## Motivation</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">## Proposed solution</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">The syntax to declare a fixed size array would be as follows:</div><div class=""><br class=""></div><div class=""> var values: (4 x Int)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span></div><div class="">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)`.</div><div class=""><br class=""></div><div class="">Initializing the individual elements of a fixed array would be similar to initialzing an existing tuple:</div><div class=""><br class=""></div><div class=""> let values: (4 x Int) = (1, 2, 3, 4)</div><div class=""><br class=""></div><div class="">Initializing all the elements to a single value would be done similar to calling an initializer on a type:</div><div class=""><br class=""></div><div class=""> let values: (4 x Int)(repeatedValue: 0) // Is this possible?</div><div class=""><br class=""></div><div class="">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]`.</div><div class=""><br class=""></div><div class="">## Detailed design</div><div class=""><br class=""></div><div class="">TBD</div><div class=""><br class=""></div><div class="">## Impact on existing code</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">## Alternatives considered</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Jan 28, 2016, at 10:23 PM, Justin Kolb <<a href="mailto:justin.kolb@gmail.com" class="">justin.kolb@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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?<div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 28, 2016, at 9:57 PM, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><br class="Apple-interchange-newline">On Jan 28, 2016, at 5:07 PM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">I find </div><div class=""><br class=""></div><div class=""><div class=""><font face="Menlo" class="">let values: (4 x Int) = (1, 2, 3, 4)</font></div></div><div class=""><br class=""></div><div class="">to be adequately cromulent. I believe this approach to be:</div><div class=""><br class=""></div><div class="">* Readable, even to someone unfamiliar with the syntax</div><div class="">* The parens before the assignment suggest something to do with tuples, and the numbers match the arity after the assignment</div><div class="">* The type is preserved in-place</div><div class="">* It's compact, elegant, simple</div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">+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?</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">-Chris</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 28, 2016, at 5:56 PM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 28, 2016, at 4:04 PM, Haravikk <<a href="mailto:e-mail@haravikk.me" class="">e-mail@haravikk.me</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On 28 Jan 2016, at 22:37, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class=""><blockquote type="cite" class="">On Jan 28, 2016, at 2:36 PM, Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com" class="">jtbandes@gmail.com</a>> wrote:<br class=""><br class="">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).<br class=""><br class="">Maybe we could take advantage of something which would be very invalid under the current grammar, namely (n T) rather than (n * T):<br class=""><br class=""> let values: (4 Int) = (1, 2, 3, 4)<br class=""></blockquote><br class="">Sure, or we could lift (4 x Int) from LLVM IR's syntax.</div></blockquote><br class=""></div><div class="">How about:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><font face="Monaco" class="">let values:Int[4] = (1,2,3,4)</font></div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><font face="Monaco" class="">let values:(Int[4]) = (1,2,3,4)</font></div><div class=""><br class=""></div><div class="">Could work too? Just some alternatives anyway, as I like the idea.</div></div></div></blockquote></div><br class=""><div class="">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.</div><div class=""><br class=""></div><div class="">-Joe</div><div class=""><br class=""></div><div class=""><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></body></html>