# Vector manifesto **URL:** \ **Category:** Discussion\ **Created:** [February 14, 2019, 9:14pm UTC](https://forums.swift.org/t/vector-manifesto/20508 "2019-02-14T21:14:07Z")\ **Posts on this page:** 1\ **Showing post:** 42
**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\ **Post date:** [February 20, 2019, 6:28pm UTC](https://forums.swift.org/t/vector-manifesto/20508/42 "2019-02-20T18:28:31Z")
> [@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](https://forums.swift.org/t/pitch-make-collection-super-convenient-and-retire-sequence/12103/65), 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. --- _[View the full topic](https://forums.swift.org/t/vector-manifesto/20508)._