That’s why I hope “array” can be made a conditional keyword, for backward compatibility. Any other keyword, for this or any other proposal, will also have this problem.
I originally was going to have fixed arrays be a “struct” with funny settings. After thinking on how I would define the shape directive and deal with any potential problems, I reconsidered and made fixed arrays be a separate kind of type. For example, enumerations are distinct kinds of types and not SwFS-es either (no matter how they’re internally implemented).
Array-segment references (via “Collection”) and nominal arrays (in my list of default members) do support the subscript operator. Immediate arrays don’t, because they are supposed to model homogenous tuples, and tuples are generally closed to extensions. You can’t use a variable index with an immediate array, just like you can’t with a tuple. (You can if you make an array-segment reference from the immediate array first.) Oh, I forgot to mention that you can use a “for”-loop with arrays. Iteration with immediate and nominal arrays work as if they were converted to an array-segment reference first. (But I think we should require an explicit conversion if you want to use “.enumerated()” or other “Collection” members, because the direct fixed array types don’t have those members.) I say “as if” so the implementors can be free to do unwrapping or any other optimizations having the elements on the stack can give.
If you use nested arrays where some extents have to flexible and others are fixed, and you want the efficiencies from not using the heap for the fixed dimensions, this can’t be avoided. — 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
