New Spitball But first:
C has one of the worst array presentation models. It has traumatized so many that those among them that grew up to be language designers themselves threw out fixed-sized arrays entirely (from Java to even current Swift!). But we’re getting through to everyone that the concept is still important, no matter how bad one realization of it is. * If you could to arrays over, why limit your indexes to 0 ..< COUNT, when you could use any range by subtracting an offset first * Once you do that, why limit yourself to Int, when anything that could be implemented as an Int (like an enumeration type) would also work. The whole point of adding types is abstraction. If you are modeling a table where the coordinates are an enumeration, why not let the language to the translation for you. There’s no need for just a Swift-y version of C’s array model. (Already Swift downplays pointers, so the “arrays are pointers with funny settings” part of the C model shouldn’t be carried over.) This isn’t a new concept; while C’s successors gave up, C’s contemporaries didn’t. There’s plenty of models to base array presentation on. Looking at an Ada page recently, I realized that I must have let my previous experience shape the keywords I chose. Now back to Spitball #3: New Keywords: * of * #indexOf * #flatten Static Array Directive: * “[“ Specifiers_opt “of” type “]” * Specifiers: Specifier | Specifier “,” Specifiers * Specifier: Extent-Range Storage-Rank_opt * Extent-Range: Low … High | Low ..< High | N (for 0 ..< N) | Enum-Type (for Enum.min … Enum.max) * Storage-Rank: Integer in 0 ..< ExtentCount; use smallest unused value if missing; all values must be used exactly once * “mutating” (or “nonmutating”) can precede the type if the directive is used for an array-segment reference Immediate Array: Use Static Array Directive with at least one extent Array-Segment Reference: Use Static Array Directive with no extents * can initialize a scoped reference with an array literal, but the reference must be in “let” mode (so you can’t reseat it and lose the only reference to the array) * If you use this construct, put in a “mutating” to let the elements be changeable if needed * This will let you use a C-like “let myArray: [of mutating Int] = [1, 2, 3, 4, 6]” without counting first, like “var myArray: [5 of Int] = [1, 2, 3, 4, 6]” would need Nominal Arrays: Use “struct” with a Static Array Directive as the base type; mutually exclusive with instance-level stored properties (Having neither is OK.) * The “subscript” definition allows zero parameters, but “[]” doesn’t allow zero arguments, so use “myArray.super” to get the inner singular value in this case * Swift allows “self” by itself, but not “super”. This will have to be changed. For loops: * Array-segment references conform to RandomAccessCollection (and possibly MutableCollection); the two definitive array types don’t * For loops will work for the definitive array types anyway * We should either define iteration in storage order or let it be implementation-defined * We should have some other syntax to let processing of elements go in parallel * Within a for-loop, use “#indexOf(X)” to get a tuple of the index coordinates of the current element; “X” is (one of) the iteration objects between the “for” and “in”; an identifier is needed so if you have nested for-loops with separate arrays, you can choose which one to inspect Dereferencing: * For immediate arrays, use "myArray.0" like tuples, it’s "myArray.(1, 2)" for multi-dimensional arrays * Convert to array-segment first if you need run-time index selection (with “[]”) * Nominal arrays come with “[]” by default Function arguments: * Use array-segment reference parameter to take definitive arrays of any size, assuming the same element type * If the definitive array is multi-dimensional, use “#flatten(myArray)” first (I’ve realized that a multi-D array should not translate to a linear ASR silently by default.) * Of course, you can use either definitive array type as a parameter too — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
