I looked up a history of programming languages on Wikipedia, and looked up a bunch of them that I heard of to see how they handle array indexing.
1. A lot of them do it the way C does it: you specify a positive integer at the spot where you give a dimension. Then at dereference-time, you insert an integer in 0..<N (or 1…N for Fortran and Cobol) in the same dimension place to determine the offset.
2. Fortran has another indexing mode, where you specify a problem-domain range (still integers), and the implementation does the translation between user- and compiler-offsets before dereference.
3. Ada takes this further by allowing any discrete type. For a dimension with a non-integer range, it just does two translations (probably optimized to a single bigger translation).
So, should we take array indexing from an implementer’s view, computing offsets? Or should we take indexing from a user’s view, translating from the problem domain? The latter effectively makes indexing a function from (Index1, Index2, …) to Element, like the example from the Swift manual where an enumeration case with associated values can be treated like a function.
I’m talking about presentation; the internals of indexing are the same in all the cases.
That list above progressively expands the scope. We can simulate [1] if we go with [3] (or [2]). But going with [1] requires a wrapper struct if we want to go the other way. Yes, those translations should be rote; but if it’s rote, should we just let the compiler do the drudgery for us?
It just seems from the last round on fixed-sized arrays, everyone besides me was going for [1]. Is that because they don’t like [2] or [3]? Or were they too different to be ever considered?
···
—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com