[swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)
Jordan Rose
jordan_rose at apple.com
Fri Jan 29 13:07:40 CST 2016
> On Jan 28, 2016, at 20:00, Chris Lattner via swift-evolution <swift-evolution at swift.org> 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].
+1 from me, for "principle of least surprise" and "principle of not making the type checker do extra work".
Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160129/651623a9/attachment.html>
More information about the swift-evolution
mailing list