[swift-evolution] Indexing (static-size) arrays: offsets or tables?
darylew at mac.com
Mon Jun 5 07:37:17 CDT 2017
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  if we go with  (or ). But going with  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 . Is that because they don’t like  or ? Or were they too different to be ever considered?
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution