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.
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]
I also think Chris Lattner has a very good plan for initializing fixed-size
arrays, which I will quote here:
On Sat, Jul 22, 2017 at 3:02 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:
>
> 1) Fixed size arrays should have an initializer to init all the elements
> to some concrete value.
> 2) They should have an init that takes a closure, and runs it once per
> element, passing in the index.
> 3) Either through a magic value or a third initializer, it should be
> possible to *explicitly* create a fixed size array with uninitialized
> garbage for the elements. This is important for specific optimizations,
> and should also come to Array as well.
>
> IMO, it isn’t a problem that C allows arrays to be uninitialized - the
> problem is that it is a really bad default.
>
> -Chris
After all, Swift is safe by default, and users can opt into unsafe
territory when necessary. There are certain algorithms which involve
filling in an array of known length in arbitrary order, and they should be
possible to implement in Swift.
There is still the matter of bikeshedding how to spell the type of a
fixed-size array. I used “[Int(3, 3)]” above, but I am nearly certain that
a better spelling exists.
Nevin
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
