[I’ve seen the WWDC 2016 Keynote and State of the Platforms videos. I haven’t seen any others so I don’t spoil myself before typing my ideas down. Apologies if this has already been covered.]
Is there any problem to adding fixed-sized arrays? From what I glanced here, it’s more like no one has gotten around to it and less like the very idea is hated.
Obviously, the main advantages are that object storage (or pointer storage for reference types) is on the stack and that the shape (i.e. the number of extents and range for each extent) is fixed at compile time. This type of, well, type can be used when the baggage of length changing isn’t needed Such arrays are also a classic type since we started system-programming languages. (I was surprised by their absence in Swift when I first read the books.) They can be mapped to a vector processing unit’s built-ins.
This:
struct ArrayOf5<T> {
let count = 5
var first: T
var second: T
var third: T
var fourth: T
var fifth: Tinit(array: [T]) {
first = array[0]
second = array[1]
third = array[2]
fourth = array[3]
fifth = array[4]
}subscript(index: Int) -> T {
get {
var preResult: T?
switch index {
case 0:
preResult = first
case 1:
preResult = second
case 2:
preResult = third
case 3:
preResult = fourth
case 4:
preResult = fifth
default:
preResult = nil
}
return preResult!
}set {
func doAssign(destination: UnsafeMutablePointer<T>) {
destination.memory = newValue
}switch index {
case 0:
doAssign(&first)
case 1:
doAssign(&second)
case 2:
doAssign(&third)
case 3:
doAssign(&fourth)
case 4:
doAssign(&fifth)
default:
doAssign(nil)
}
}
}}
shouldn’t be better supported than directly having built-in fixed-sized arrays. (I’ve wondered if we should have a library or built-in arrays. I’ve decided that even if we add a library, we still need the built-in.) Although I parametrized the type, altering the shape (right now 1 dimension of 5 elements) doesn’t scale since it requires lexical change. Internally, a built-in array type would be something like this, modulo optimizations and not having to come up with names for each element.
···
—————
[The following sections are my ideas about implementation; we don’t have to use them.]
What should array type expressions look like in code?
Since generics (currently) only use type-based parameters, we can’t do something C++-ish like “array<T, 1, 4, 3>”. I did have a thought of “[MyType; 5]”, but that seemed too close to current arrays. I was shocked to discover that Rust uses that syntax. However, it’s still to bad to use now because ‘[MyType]” would mean something different that it does currently (zero-dimensional array of a single unit instead of one-dimensional array of arbitrary number of elements).
Since arrays are product types (I think), let’s use multiplication syntax:
var myArray: MyType * [6] // This is an array of six elements, each of `MyType`
var myArray2: MyType * [6] * [5] // This is an array of five elements, each a six-element array of `MyType`
var myArray3: MyType * [3, 4] // This is an array of three-by-four, each element of `MyType`
The “[ SHAPE ]” syntax affects the type expression to its left. An empty list is not allowed since, although array-literal syntax allows empty lists, the subscript operation does not. Note, to keep the syntax regular, the first subscript when using “myArray2” is for five elements, i.e. “0..<5”, and the second (if any) is for six, the reverse lexical order of declaration. This is because we don’t have C’s cute “declaration equals usage” type syntax. Also note that “myArray3” requires a single subscript call with two coordinates in it to dereference. Supplying only one coordinate is nonsensical. (“myArray2” is the other way when you want to dereference a “MyType” value.)
Of course, not using a shape expression gives you a zero-dimensional array (i.e. a regular variable) of your base type by default. (So, it would actually be "0 + extents(MyType.self)" dimensions.)
Or we could just do it the same way C does it (i.e. “MyType[8]”), and preserve nested arrays having the same lexical order in declaration and dereference. We could even forbid multi-dimensional arrays and just do nested single-dimensional arrays like C (and move multi-dimensionality to wrapper structs), but I feel that would be giving up on improving the abstraction.
——
What about row vs. column order?
If you stick with chaining one-dimensional arrays, you get only row-order, just like C (which can only do nested one-dimensional arrays). If you use a multi-extent shape expression, you can override the order:
var myArray1: MyType * [3, 4] * #rank[0, 1] // Default; row-order
var myArray2: MyType * [3, 4] * #rank[1, 0] // Reversed; column-order
var myArray3: MyType * [3, 4, 5] * #rank[0, 2, 1] // Scrambled
The array literal attached to the rank command has to contain every value in 0..<count exactly once. The position of the “0” value is the spacing with the longest span, “count - 1” is the adjacent elements level.
A rank command can only appear directly after a shape expression or an element type expression, and not after another rank command. The command’s literal must have the same length as the number of extents of the corresponding shape expression. A rank command following an element type expression, whether it’s a non-static-array type or a static-array type hidden behind a type alias, is treated as a zero-dimensional array so “#rank” is the only legal rank command for them.
The rank command does not pierce type aliases; “#rank” is the only valid command for them. The alias itself can have a rank command, which affects all objects declared with that alias, and cannot be overridden. (If the alias doesn’t have a rank command, the index storage priority is fixed to the default.) Should a rank-stripping command be added? Should an rank command that pierces aliases and/or overrides previous ranks be added?
Types that differ in number of shape commands, number of extents within corresponding commands, size of corresponding extents, index storage priorities, or element type are different types. We should have a function that can reshape an array if the total number of the outermost non-static-array objects are the same. (The function could reshape a non-static-array type to a static array of one element with any nesting.)
(If we give up on improving the abstraction compared to C, this rank order would be simulated in a wrapper struct that rearranges the indices.)
——
What about initialization?
I didn’t use initialization expressions before because it’s hard. We’ll have to work on this.
Zero-dimensional arrays (i.e. a regular non-static-array type) are iniitalized as usual.
A one-dimensional static-array gets initialized like a current dynamic array. But the syntax given below will also be accepted (with just one coordinate, of course).
For higher-dimensional arrays, we need something like:
[(0, 0, 0): myFirstValue, (2, 4, 1): mySecondValue, …]
[(0, 0): myFirstValue, (0, 1): mySecondValue, default: myDefaultValue]
and/or:
var myArray: MyType * [3, 4] = { return 2 * $0 + 7 * $1 }
(We can use “myParam1, myParam2 in” syntax for that last one too.) Can/could we have an array expression that is part (XX, YY) and part $0/$etc formula? Maybe with “_” and/or “case” and/or “where” to differentiate which elements get the $0/$etc and which ones get a “default:” phrase? Maybe the _/case/where could be used within incomplete (XX, YY)-style indexing?
——
Should there be flexible-ending arrays? Other value types?
Let’s say that at most one extent in a shape expression can be “any” instead of a compile-time integer expression. Let’s restrict the “any” dimension to be the rank-0 one, using “#rank” to override if you didn’t put the “any” first. Let’s call these flexible-ending static-arrays.
Flexible-ending static-arrays could be used like the “MyType” expression in C. Frequently it can be used as a function parameter without having to specialize for each possible array length. In other words, for a given static array type “MyType * […, N, …]”, it can be passed into a function parameter that is declared as “MyType * […, any, …]”. Could there be an automatic way to pass in the value of “N”, or would we have to resort to using another function parameter or some other out-of-band information and trusting the user to synchronize correctly?
It should be possible to pass in different-shaped arrays to said function parameters with a reshape call, as long as the total number of elements is a multiple of the span across the “any”-ed extent. Should such a function parameter also take a "[MyInnerType]” dynamic array objects, where “MyInnerType” is what you get after stripping the outermost, “any”-ed, extent?
A flexible-ending struct is one with a flexible-ending type as its last stored property. A flexible-ending enum is a enum with attributed cases and at least one case ends its tuple with a flexible-ending type. Flexible-ending types cannot appear anywhere else as a stored property in a struct or enum. Should we use “final” to mark a struct’s flexible ending property? Somehow adapt this for enums too? (Right now, “final” is only used for classes.) Flexible-ending structs and enums can be used in function parameters too, allowing different lengths for the same parameter. Like static-arrays, a struct or enum that matches a flexible function parameter except that its would-be flexible part is fixed can be passed through said parameter. (It’s the same rule since all flexible struct and enums have to have a nested flexible array at their end.)
Besides as function parameters, a flexible-ending object can be declared inside a function/method or as a global. I’m not sure how to do heap versions yet. If the object is immutable (i.e. “let”), the initialization block has to cover all the elements without using $0/$etc or “default:” so the size can be determined. I’m not sure how mutable objects are supposed to work here. I’ll need your ideas the most here, assuming we keep this feature. It was inspired by seeing code in Ada (discriminated record) and C (“MyType[1]” as last field in struct, then allocate with malloc) doing this.
Oh yeah, a flexible-ending static-array, including those that are parts of flexible-ending structs and enums, must have a inflexible base type. (Otherwise lies madness.)
(If we keep this feature, maybe it should be limited to one-dimensional arrays.)
—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com