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

Reply via email to