[swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)

[Joe Groff]

> 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[0]', giving an integer literal subscript the added power to produce the Nth value as the Nth concrete type of the tuple.

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160129/d576e910/attachment.html>