# Sparse (fixed-size) array literal syntax **URL:** \ **Category:** Discussion\ **Created:** [June 2, 2017, 5:49am UTC](https://forums.swift.org/t/sparse-fixed-size-array-literal-syntax/6042 "2017-06-02T05:49:47Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![CTMacUser](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ctmacuser/32/1802_2.png) [@CTMacUser](https://forums.swift.org/u/CTMacUser)\ **Post date:** [June 2, 2017, 5:49am UTC](https://forums.swift.org/t/sparse-fixed-size-array-literal-syntax/6042/1 "2017-06-02T05:49:47Z")
Current array literal syntax (i.e. “[a, b, c]”) works for dense and/or linear arrays, but isn’t so great later on when we add fixed-size arrays and the defined (non-zero) elements are sparse and/or the array is multi-dimensional (not nested). In these cases I’m thinking of leading each element with its coordinate: … 6: a, … // complete value, linear array … (1, 2): b, … // complete value, multi-dimensional array … (let x, let y) where y % 2 == 0: c \* y + x, … // pattern of qualifying coordinates … default: d, … // when no other initializer covers an element (Use “\_” instead?) A complete coordinate beats a pattern, which beats a default. The issue I see here is that I’m using a colon as a separator between the coordinate expression and the value expression. Would that interfere with dictionary literal syntax? Would it help the we’ll most likely have to demand that the object receiving the literal has to have its type specified (with whatever syntax we agree on), as either a declared object with a type annotation or a function parameter (for a function either without overload or with the variant used otherwise made clear)? > **···** > > — > Daryle Walker > Mac, Internet, and Video Game Junkie > darylew AT mac DOT com ---
**Author:** ![jadengeller](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jadengeller/32/11544_2.png) [@jadengeller](https://forums.swift.org/u/jadengeller)\ **Post date:** [June 2, 2017, 6:11am UTC](https://forums.swift.org/t/sparse-fixed-size-array-literal-syntax/6042/2 "2017-06-02T06:11:04Z")
Comments inline. > Current array literal syntax (i.e. “[a, b, c]”) works for dense and/or linear arrays, but isn’t so great later on when we add fixed-size arrays and the defined (non-zero) elements are sparse and/or the array is multi-dimensional (not nested). In these cases I’m thinking of leading each element with its coordinate: > > … 6: a, … // complete value, linear array You can already do this with a dictionary since a Int can be used as the key type. > … (1, 2): b, … // complete value, multi-dimensional array This would be possible if tuples of hashable types were considered hahable. Right now, you could define some point type. > … (let x, let y) where y % 2 == 0: c \* y + x, … // pattern of qualifying coordinates You can build this sort of thing using an initializer that takes a function. You wouldn’t get this sugar, but I don’t think it is necessary. > … default: d, … // when no other initializer covers an element (Use “\_” instead?) This one is a bit harder. I think it would be reasonable for there to exist some subtype of the dictionary literal type that also included information about a default value, but I think this should be motivated by the Swift standard library (e.g. a defaultable dictionary type). Right now, you can just make literal syntax default to a `nil` default value, and then you can define a function that nil-coalesces the default value. This is definitely less elegant, but I don’t think it matters a whole lot. ```swift Sparse([1: “foo”, 5: “bar”, 100: “baz”], default: “”) ``` > A complete coordinate beats a pattern, which beats a default. The issue I see here is that I’m using a colon as a separator between the coordinate expression and the value expression. Would that interfere with dictionary literal syntax? Would it help the we’ll most likely have to demand that the object receiving the literal has to have its type specified (with whatever syntax we agree on), as either a declared object with a type annotation or a function parameter (for a function either without overload or with the variant used otherwise made clear)? > > — > Daryle Walker > Mac, Internet, and Video Game Junkie > darylew AT mac DOT com > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > swift-evolution mailing list > swift-evolution@swift.org > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) Cheers, Jaden Geller > **···** > > > On Jun 1, 2017, at 10:49 PM, Daryle Walker via swift-evolution \ wrote: ---
**Author:** ![CTMacUser](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ctmacuser/32/1802_2.png) [@CTMacUser](https://forums.swift.org/u/CTMacUser)\ **Post date:** [June 2, 2017, 7:22am UTC](https://forums.swift.org/t/sparse-fixed-size-array-literal-syntax/6042/3 "2017-06-02T07:22:00Z")
I’m not asking how to do this in current Swift with current types, but fixed-sized arrays in a future Swift. I’m asking if this mixing of array- and dictionary-literals for these advanced-array literals would be too hard for compiler implementors to implement. > **···** > > > On Jun 2, 2017, at 2:11 AM, Jaden Geller \ wrote: > > > > Comments inline. > > > > > On Jun 1, 2017, at 10:49 PM, Daryle Walker via swift-evolution \\> wrote: > > > > > > Current array literal syntax (i.e. “[a, b, c]”) works for dense and/or linear arrays, but isn’t so great later on when we add fixed-size arrays and the defined (non-zero) elements are sparse and/or the array is multi-dimensional (not nested). In these cases I’m thinking of leading each element with its coordinate: > > > > > > … 6: a, … // complete value, linear array > > > > You can already do this with a dictionary since a Int can be used as the key type. > > > > > … (1, 2): b, … // complete value, multi-dimensional array > > > > This would be possible if tuples of hashable types were considered hahable. Right now, you could define some point type. > > > > > … (let x, let y) where y % 2 == 0: c \* y + x, … // pattern of qualifying coordinates > > > > You can build this sort of thing using an initializer that takes a function. You wouldn’t get this sugar, but I don’t think it is necessary. > > > > > … default: d, … // when no other initializer covers an element (Use “\_” instead?) > > > > This one is a bit harder. I think it would be reasonable for there to exist some subtype of the dictionary literal type that also included information about a default value, but I think this should be motivated by the Swift standard library (e.g. a defaultable dictionary type). > > > > Right now, you can just make literal syntax default to a `nil` default value, and then you can define a function that nil-coalesces the default value. This is definitely less elegant, but I don’t think it matters a whole lot. > > > > ```swift > > Sparse([1: “foo”, 5: “bar”, 100: “baz”], default: “”) > > > > ``` > > — > Daryle Walker > Mac, Internet, and Video Game Junkie > darylew AT mac DOT com ---
**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\ **Post date:** [June 2, 2017, 4:45pm UTC](https://forums.swift.org/t/sparse-fixed-size-array-literal-syntax/6042/4 "2017-06-02T16:45:15Z")
"Literals" like this are obviously complicated to the point that you would be much better off just using an initializer that takes a function to construct each element. There's no point in reinventing switches in the array-literal syntax. John. > **···** > > > On Jun 1, 2017, at 10:49 PM, Daryle Walker via swift-evolution \ wrote: > > > > Current array literal syntax (i.e. “[a, b, c]”) works for dense and/or linear arrays, but isn’t so great later on when we add fixed-size arrays and the defined (non-zero) elements are sparse and/or the array is multi-dimensional (not nested). In these cases I’m thinking of leading each element with its coordinate: > > > > … 6: a, … // complete value, linear array > > … (1, 2): b, … // complete value, multi-dimensional array > > … (let x, let y) where y % 2 == 0: c \* y + x, … // pattern of qualifying coordinates > > … default: d, … // when no other initializer covers an element (Use “\_” instead?) > > > > A complete coordinate beats a pattern, which beats a default. The issue I see here is that I’m using a colon as a separator between the coordinate expression and the value expression. Would that interfere with dictionary literal syntax? Would it help the we’ll most likely have to demand that the object receiving the literal has to have its type specified (with whatever syntax we agree on), as either a declared object with a type annotation or a function parameter (for a function either without overload or with the variant used otherwise made clear)? ---
**Author:** ![jadengeller](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jadengeller/32/11544_2.png) [@jadengeller](https://forums.swift.org/u/jadengeller)\ **Post date:** [June 2, 2017, 7:56am UTC](https://forums.swift.org/t/sparse-fixed-size-array-literal-syntax/6042/5 "2017-06-02T07:56:23Z")
Why would this not be possible with fixed sized arrays? Theoretically you could create a type that wrapped a fixed array and make it conform to whatever protocol you want, including the “ExpressibleBy” protocols. > **···** > > > On Jun 2, 2017, at 12:22 AM, Daryle Walker \ wrote: > > > > > On Jun 2, 2017, at 2:11 AM, Jaden Geller \\> wrote: > > > > > > Comments inline. > > > > > > > On Jun 1, 2017, at 10:49 PM, Daryle Walker via swift-evolution \\> wrote: > > > > > > > > Current array literal syntax (i.e. “[a, b, c]”) works for dense and/or linear arrays, but isn’t so great later on when we add fixed-size arrays and the defined (non-zero) elements are sparse and/or the array is multi-dimensional (not nested). In these cases I’m thinking of leading each element with its coordinate: > > > > > > > > … 6: a, … // complete value, linear array > > > > > > You can already do this with a dictionary since a Int can be used as the key type. > > > > > > > … (1, 2): b, … // complete value, multi-dimensional array > > > > > > This would be possible if tuples of hashable types were considered hahable. Right now, you could define some point type. > > > > > > > … (let x, let y) where y % 2 == 0: c \* y + x, … // pattern of qualifying coordinates > > > > > > You can build this sort of thing using an initializer that takes a function. You wouldn’t get this sugar, but I don’t think it is necessary. > > > > > > > … default: d, … // when no other initializer covers an element (Use “\_” instead?) > > > > > > This one is a bit harder. I think it would be reasonable for there to exist some subtype of the dictionary literal type that also included information about a default value, but I think this should be motivated by the Swift standard library (e.g. a defaultable dictionary type). > > > > > > Right now, you can just make literal syntax default to a `nil` default value, and then you can define a function that nil-coalesces the default value. This is definitely less elegant, but I don’t think it matters a whole lot. > > > > > > ```swift > > > Sparse([1: “foo”, 5: “bar”, 100: “baz”], default: “”) > > > > > > ``` > > > > I’m not asking how to do this in current Swift with current types, but fixed-sized arrays in a future Swift. I’m asking if this mixing of array- and dictionary-literals for these advanced-array literals would be too hard for compiler implementors to implement. > > > > — > > Daryle Walker > > Mac, Internet, and Video Game Junkie > > darylew AT mac DOT com ---
**Author:** ![CTMacUser](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ctmacuser/32/1802_2.png) [@CTMacUser](https://forums.swift.org/u/CTMacUser)\ **Post date:** [June 2, 2017, 8:02am UTC](https://forums.swift.org/t/sparse-fixed-size-array-literal-syntax/6042/6 "2017-06-02T08:02:48Z")
I DO want it to be possible with future fixed-sized arrays. This is not a user-side question, but implementor-side. I’m asking if the parsing routines for it would conflict with the current array- and dictionary-literal rules, since they will co-exist. If this syntax would make determining whether we have an enhanced array literal or a dictionary literal too hard, then we should change it before anything is finalized. > **···** > > > On Jun 2, 2017, at 3:56 AM, Jaden Geller \ wrote: > > > > Why would this not be possible with fixed sized arrays? Theoretically you could create a type that wrapped a fixed array and make it conform to whatever protocol you want, including the “ExpressibleBy” protocols. > > — > Daryle Walker > Mac, Internet, and Video Game Junkie > darylew AT mac DOT com ---
**Author:** ![jadengeller](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jadengeller/32/11544_2.png) [@jadengeller](https://forums.swift.org/u/jadengeller)\ **Post date:** [June 2, 2017, 8:06am UTC](https://forums.swift.org/t/sparse-fixed-size-array-literal-syntax/6042/7 "2017-06-02T08:06:44Z")
I don’t know if you’re aware, but you can extend arbitrary nominal types with literal syntax. ```swift extension FixedSizedArray: ExpressibleAsDictionaryLiteral { … } ``` Nothing special needs to be done on the implementation side to make this possible. If fixed sized arrays are not nominal types (like tuples, unlike `Array`s), then you will only be able to give this sugar to types that wrap them, not the type itself (w/o special support). What’s the discussion on enhanced array and dictionary literals? I think I missed that. Cheers, Jaden Geller > **···** > > > On Jun 2, 2017, at 1:02 AM, Daryle Walker \ wrote: > > > > > On Jun 2, 2017, at 3:56 AM, Jaden Geller \ wrote: > > > > > > Why would this not be possible with fixed sized arrays? Theoretically you could create a type that wrapped a fixed array and make it conform to whatever protocol you want, including the “ExpressibleBy” protocols. > > > > I DO want it to be possible with future fixed-sized arrays. This is not a user-side question, but implementor-side. I’m asking if the parsing routines for it would conflict with the current array- and dictionary-literal rules, since they will co-exist. If this syntax would make determining whether we have an enhanced array literal or a dictionary literal too hard, then we should change it before anything is finalized. > > > > — > > Daryle Walker > > Mac, Internet, and Video Game Junkie > > darylew AT mac DOT com ---
**Author:** ![CTMacUser](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ctmacuser/32/1802_2.png) [@CTMacUser](https://forums.swift.org/u/CTMacUser)\ **Post date:** [June 2, 2017, 9:38am UTC](https://forums.swift.org/t/sparse-fixed-size-array-literal-syntax/6042/8 "2017-06-02T09:38:36Z")
> I don’t know if you’re aware, but you can extend arbitrary nominal types with literal syntax. > > ```swift > extension FixedSizedArray: ExpressibleAsDictionaryLiteral { … } > > ``` > > Nothing special needs to be done on the implementation side to make this possible. If fixed sized arrays are not nominal types (like tuples, unlike `Array`s), then you will only be able to give this sugar to types that wrap them, not the type itself (w/o special support). I don’t think that’ll work with the “where” clauses and “default” values in the new syntax. > What’s the discussion on enhanced array and dictionary literals? I think I missed that. This is the discussion. I’m asking if this “enhanced array” syntax I just came up with would interfere with the existing dictionary syntax from a parsing perspective. > **···** > > > On Jun 2, 2017, at 4:06 AM, Jaden Geller \ wrote: > > — > Daryle Walker > Mac, Internet, and Video Game Junkie > darylew AT mac DOT com ---
**Author:** ![jadengeller](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jadengeller/32/11544_2.png) [@jadengeller](https://forums.swift.org/u/jadengeller)\ **Post date:** [June 2, 2017, 9:46am UTC](https://forums.swift.org/t/sparse-fixed-size-array-literal-syntax/6042/9 "2017-06-02T09:46:58Z")
Comments inline. > > I don’t know if you’re aware, but you can extend arbitrary nominal types with literal syntax. > > > > ```swift > > extension FixedSizedArray: ExpressibleAsDictionaryLiteral { … } > > > > ``` > > > > Nothing special needs to be done on the implementation side to make this possible. If fixed sized arrays are not nominal types (like tuples, unlike `Array`s), then you will only be able to give this sugar to types that wrap them, not the type itself (w/o special support). > > I don’t think that’ll work with the “where” clauses and “default” values in the new syntax. I explained point-by-point which of these would be possible. If you reference the original message, I stated that the “where” sugar could instead be expressed with a lambda function. Personally, I’m against adding this new “where" sugar to the language, especially since the alternative seems no worse. I do think the “default” sugar is a good idea (as I stated there as well), but I don’t think it must be considered with fixed length arrays. It seems like an entirely additive and orthogonal feature. > > What’s the discussion on enhanced array and dictionary literals? I think I missed that. > > This is the discussion. I’m asking if this “enhanced array” syntax I just came up with would interfere with the existing dictionary syntax from a parsing perspective. I see. The first two cases (which are just normal dictionary syntax) are already possible. I don’t know about the third “where” case, but I don’t think it’s necessary. The 4th case seems possible since the keyword “default” cannot be used as an identifier. > — > Daryle Walker > Mac, Internet, and Video Game Junkie > darylew AT mac DOT com Cheers, Jaden Geller > **···** > > > On Jun 2, 2017, at 2:38 AM, Daryle Walker \ wrote: > > > > > On Jun 2, 2017, at 4:06 AM, Jaden Geller \ wrote: