Comments inline. > On Jun 1, 2017, at 10:49 PM, Daryle Walker via swift-evolution > <swift-evolution@swift.org> 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. ``` 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 Cheers, Jaden Geller
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution