[swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)
jgroff at apple.com
Fri Jan 29 13:20:23 CST 2016
> On Jan 28, 2016, at 9:49 PM, Chris Lattner <clattner at apple.com> wrote:
> On Jan 28, 2016, at 9:25 PM, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>>>> +1. I like this syntax too, and with Joe’s other proposed extensions, it would all fit together nicely. Anyone interested in writing up a proposal?
>>> One other tweak worth considering: instead of subscript being defined on a tuple as returning a common type, a more modest proposal would be that subscript is defined on tuples that:
>>> a) have no element labels.
>>> b) all have the same element type.
>>> This would solve the fixed size array use-case, be much easier to implement, and not have surprising performance issues promoting things to Any. It is also consistent with the fact that we don’t infer the type of [Int(), Float()] to [Any].
>> I'm not sure this prevents anything, since labeled tuples implicitly convert to unlabeled tuples, and tuples support structural subtyping, so (Derived, Derived) is-a (Base, Base) is-an (Any, Any). Both of those type rules might be worth reconsidering on their own, of course, but otherwise you could still backdoor your way into subscripting a heterogeneous and/or labeled tuple via those conversions.
> Right, I’d much rather see:
> let v = (someHeterogenousTuple as (4 x Any))[i]
> Rather than:
> let v = someHeterogenousTuple[i]
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution