[swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)
clattner at apple.com
Fri Jan 29 15:42:13 CST 2016
On Jan 29, 2016, at 11:20 AM, Joe Groff <jgroff at apple.com> wrote:
>> given that the subscripting syntax is intended to be an efficient “array index” operation. I’m uncomfortable with an expensive representation-transforming operation that potentially involves heap allocation (when the tuple element is a struct larger than the Any existential rep) happening accidentally.
>> That said, perhaps there is a middle ground: we can use the same rules we use for array literals since array literals also don’t merge to Any as their common type. I see no concerns with using the common type for a heterogenous tuple of classes that have a common base class, for example, because that won’t be a representation change.
>> That said, I don’t think this will be a very important use case, so I’d be happy with subsetting that out of the base proposal, and adding it when there is a specific motivation for it.
> Sure. What do you think about special-casing subscripting by integer literal? We could potentially supersede the 'x.0' syntax with 'x', giving an integer literal subscript the added power to produce the Nth value as the Nth concrete type of the tuple.
Personally, I wouldn’t be thrilled with that directly. This would make tuple accesses more “array like” than “struct like”. For heterogenous tuples, they are unquestionably more struct like.
I feel like adding the subscript only in the case of homogenous tuples nicely splits the different here, and it seems like it would fit better into the generics model (though I’m much less sure about that).
More information about the swift-evolution