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

Joe Groff jgroff at apple.com
Thu Jan 28 23:25:49 CST 2016


> On Jan 28, 2016, at 8:00 PM, Chris Lattner <clattner at apple.com> wrote:
> 
>> 
>> On Jan 28, 2016, at 7:57 PM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
>> 
>> 
>>> On Jan 28, 2016, at 5:07 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> I find 
>>> 
>>> let values: (4 x Int) = (1, 2, 3, 4)
>>> 
>>> to be adequately cromulent. I believe this approach to be:
>>> 
>>> * Readable, even to someone unfamiliar with the syntax
>>> * The parens before the assignment suggest something to do with tuples, and the numbers match the arity after the assignment
>>> * The type is preserved in-place
>>> * It's compact, elegant, simple
>> 
>> +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.

-Joe

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


More information about the swift-evolution mailing list