> I’m not saying that tuple member names are “true integers” (although, with 
> Reflection…). I understood that, semantically, the reason we refer to 
> elements .0, .1 and .2 of a tuple because that’s their name, not necessarily 
> because its their position in the tuple. My point is that for a fixed-size 
> array like a [3; Double] vector, because you know what to expect at each 
> location, those indices are *both* ordinal *and* nominal. Subscripting [0] or 
> [1] from that FSA has the same conceptual meaning as accessing .x or .y on an 
> equivalent struct. What I’m trying to say is: for a FSA, the index *is* the 
> member name, just like the declaration-order number is for tuples.
I think one important aspect of an array is that the slots don't have a name at 
all...

> I think the difference is that, for a fixed-size Array, the absolute 
> positions also generally have external meaning which is known to the 
> programmer but not reflected in the type-system. For example, that a [3; 
> Double] vector is supposed to be interpreted as (x, y, z) components, in that 
> order.
> 
> We can do better than to expose a 3-element vector as a list of 3 unlabelled 
> values. Or even a n-dimensional matrix just as a series of numbers.
I don't think we can — because a matrix is nothing but a bunch of numbers.
How would you name the elements in 600 × 2000 matrix?
Shorthands like x, y, z are only used in a very restricted environment that has 
little to do with real math.

> A better system may require meta-programming features we don’t support yet, 
> and that’s fine, but I would really like us to focus on the actual use-cases 
> of FSAs and to consider ways of making those great, rather than checking off 
> a feature that we have to have ‘just because’.
As I said: I don't think there is a better system, but what features should 
that be?

> I remember that in the first Swift beta, you were allowed to mutate a “let” 
> Array as long as you didn’t change its length. The community didn’t like it 
> and things moved to COW instead.
… and it made a lot of sense, because "can't be resized" is not a very useful 
feature when you can't reason about the size, and "can't be modified at all" 
helps a lot.
Fixed-size arrays are completely different when they expose their size to the 
type checker.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to