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

[Chris Lattner]

On Jan 28, 2016, at 9:25 PM, Joe Groff <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.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160128/74d24f0a/attachment.html>