> On Jul 23, 2017, at 2:07 PM, Nevin Brackett-Rozinsky via swift-evolution > <swift-evolution@swift.org> wrote: > > I think fixed-size arrays should be a nominal type like any other. They > should be able to have methods, conform to protocols, be extended with new > behavior, and generally present a user-experience similar to what arrays > already have. In particular, they should conform to Collection and to > ExpressibleByArrayLiteral.
Nominal types have to be completely initialized in their initializer, and I don’t think that should change. But we want to allow arrays to start off uninitialized, instead of a blanket initialization that would be paved over by the real initial data. That’s one reason FSAs are compound types. Another reason is that they’re kind-of low level, like tuples. As I said in some other responses, the solution to slapping methods/protocols/other-new-interfaces to compound types is to make a strong type-alias of that type and add your interface there. (Once we have strong type-aliases, of course.) I have fixed-size arrays to be compound types because > If we are going to use semicolons at all, it should be to demarcate the rows > of a 2-dimensional array, as that will be one of the most common use-cases: > > let identity3x3: [Int(3, 3)] = [1, 0, 0; > 0, 1, 0; > 0, 0, 1] That doesn’t seem scalable to higher dimensions. — 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
