EVEN MORE Recent Updates (Note: I had to use "d,e,f" instead of "a,b,c" or "x,y,z" because those turn into tags):
There has been discussion about using an [d,e,f] syntax for multidimensional arrays like in C# (These would be TRULY multidimensional, rather than being arrays of
pointers to arrays, etc.). This sparked a lot of possible changes, which I am just going to paste in here:
I'd like to consider something similar for OPIA, but there are some issues that would need addressing if I do: (1) To keep [,] rectangular (versus the jagged [][]), There would have to be a way to embed (or specify) size information (OPIA does not currently do this for native-compatibility reasons). (2) To avoid ambiguity, [d][e] should mean something different than [d,e]. ... Let's look at this step by step so we can decide on a good setup altogether:
1 2 3 4 5 6 7 8 9 10 11
| // Current setup:
[]byte // Points to a byte-array [5]byte // IS a (static) byte-array (5 values) [_]byte // Same as above, but size is determined from usage *[5]byte // Same as []byte, but requires/assumes the underlying array is 5 bytes
[5][5]byte // An array of five [5]byte values (no pointers!) [5][]byte // (static) Array of five []byte values (five pointers) [][5]byte // Points to an array of five [5]byte values [][]byte // Points to an array of pointers to arrays |
I could deal with (issue 1) by providing a way to explicitly embed size information at the front of an array:
1 2 3 4
| // Hypothetical way to embed size-information: [byte]byte // A (static) byte-array, prefixed by a byte to store the size [word]byte // A (static) byte-array, prefixed by a word to store the size *[byte]byte // Pointer to such an array |
I could deal with (issue 2) by making every
inner set of square brackets [...] become a pointer (e.g. make [d][e] ALWAYS "jagged" and [d,e] ALWAYS rectangular); and for symmetry, I could have the outermost [...] ONLY be a pointer if the * is used. It would like like this (I will just say "array" for "static array", and "pointer to array" otherwise):
1 2 3 4 5 6 7 8 9 10 11 12 13 14
| []byte // Array of (some determinable number of) bytes (previously indicated as [_]byte) [5]byte // Array of 5 bytes [byte]byte // Array of bytes (prefixed with a byte to indicate the size)
*[]byte // Pointer to an array of bytes *[5]byte // Pointer to an array of 5 bytes *[byte]byte // Pointer to a (byte-) size-prefixed array of bytes
[][]byte // Array of *[]byte values. [5][5]byte // Array of five *[5]byte values. [5,5]byte // Array of five [5]byte values (no pointers) [5][5,5]byte // Array of five *[5,5]byte values [5,5,5,5]byte // A 4-Dimensional array of bytes (no pointers) [5,5][5,5]byte // 2D array of pointers to [5,5]byte values |
This seems all well and good so far ([]T has become *[]T, but [5]*[5]T has also become just [5][5]T, and [5][5]T has become [5,5]T). However, since you cannot even COMPUTE a 2D index without at
least knowing the
inner-most dimensions of a multidimensional array (since it is all internally stored as a 1D array), you would have to specify (at least some of) the dimensions when working with pointers:
1 2 3 4 5 6
| [,]byte // Static 2D array (NOTE: the sizes have to be determinable!) *[,]byte // ERROR! (cannot even COMPUTE where [d,e] is without the inner dimension) *[,5]byte // Pointer to a [?,5]byte (ok: [d,e] is [5*d+e]) *[,byte]byte // (also ok, since [d,e] is [SIZE*d+e], and size is stored as a leading byte) *[byte,]byte // ERROR! (It's the inner dimension that matters) *[5,5]byte // Pointer to a [5,5]byte -- Very ok |
I'd be ok with allowing a multidimensional array to be treated as an array with fewer dimensions:
1 2 3 4 5 6 7 8 9
| [3,4,5]byte arr; *[3,4,5]byte p3 = &arr; // p3[d,e,f] refers to arr[d,e,f] *[,5]byte p2 = &arr; // treat arr as a [12,5]byte (e.g. p2[4*d + e, f]) *[]byte p1 = &arr; // treat arr as a [60]byte (e.g. p1[5*4*d + 5*e + f])
// I'd like NOT to allow this: arr[d] // gives the dth [4,5]byte value arr[d,e] // gives the [d,e]th [5]byte value // ... because it means that arr[d][e][f] is the same as arr[d,e,f] |