Vector manifesto

[taylorswift]

@CTMacUser

Pre-C array designs, at least in Fortran and COBOL, where multi-dimensional. The designers of C ripped that out, probably because C was meant as a to-the-metal portable assembly language. We are not bound to that, like many of the ways Swift already eschew keeping copied-over C features primitive (big example: enumeration types). I'm anti-ripping it back in because the partition between extents is user-valuable design information. I'm not sure how multi-dimensionality is supposed to work in @taylorswift's design, besides dumping it and go with simple nesting, like C and every other C-inspired language does.

@CTMacUser

Existential arrays are also supported. I'm guessing that they'll be a bundle of a pointer to the array's data block and a reference to the object's witness table. Obviously, I'm imaging a new type of witness table entry. It would have a reference to the element type's witness table, a cached copy of the total number of elements, description of the SIMD status (if any), the number of extents, then a variadic list of each extent count. (The total number of elements is cached so we don't have to do the multiplication each time.)

i just want to remind everyone that, having followed Daryle’s original push to add FSAs to the language, it failed because the proposed design was so complex and tried to cover too many esoteric use cases like zero-dimensional arrays and shape-casting. The for _ in loop-ability also felt bolted-on and the proposal would be almost entirely implemented as compiler magic, with no benefits to the rest of the language.

@CTMacUser

Maybe we need to support a [whatever ; @vector(directions) Int] where the "directions" are specific instructions, so we can force an option, like 4x16, 16x4, or 1x64. Storage is generally row-major, but the compiler can switch it up behind the scenes when vectorization is added. If a vector shape, element type, or combination is not supported, then the compiler can flag an error.

this does not feel like it fits in with the direction of the language, especially since we have actual SIMD types now. there should be no reason to add an explicit “SIMD” attribute to a non-SIMD type to try and get the compiler to make it SIMD behind your back.

@CTMacUser

Since extent counts besides 1 are supported, automatic Sequence support would be awkward. But I was about to propose a reworking of the Sequence / Collection hierarchy, and fixed-size arrays could be made to conform to those, where single-dimension arrays could conform to MutableCollection too.

this has been proposed before, and i think it’s a nonstarter considering how integral these protocols are to the language. switching up the hierarchy would be massively source breaking and it’s unclear if changing it up would even be an improvement since basically any aggregate protocol hierarchy with a sane number of protocols would involve some tradeoffs.