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

[Justin Kolb]

I will make an attempt at a first draft given what I’ve read in this thread. I’m a little fuzzy on how to proceed as the process document makes mention of using the template and getting refinements on the mailing list before making a PR with the proposal. I have been having trouble finding examples of that in prior threads. Should I post the initial markdown to the thread?

> On Jan 28, 2016, at 9:57 PM, Chris Lattner <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?
> 
> -Chris
> 
> 
>> 
>> -- E
>> 
>> 
>>> On Jan 28, 2016, at 5:56 PM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>>> On Jan 28, 2016, at 4:04 PM, Haravikk <e-mail at haravikk.me <mailto:e-mail at haravikk.me>> wrote:
>>>> 
>>>> 
>>>>> On 28 Jan 2016, at 22:37, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>> 
>>>>>> On Jan 28, 2016, at 2:36 PM, Jacob Bandes-Storch <jtbandes at gmail.com <mailto:jtbandes at gmail.com>> wrote:
>>>>>> 
>>>>>> I like this idea, but the syntax seems dangerously close to a call site for  "func *(lhs: Int, rhs: Any.Type)"  (which is obviously ill-advised, but it is allowed).
>>>>>> 
>>>>>> Maybe we could take advantage of something which would be very invalid under the current grammar, namely (n T) rather than (n * T):
>>>>>> 
>>>>>>    let values: (4 Int) = (1, 2, 3, 4)
>>>>> 
>>>>> Sure, or we could lift (4 x Int) from LLVM IR's syntax.
>>>> 
>>>> How about:
>>>> 
>>>> 	let values:Int[4] = (1,2,3,4)
>>>> 
>>>> While it looks a bit like a subscript, it doesn’t make sense in a type declaration at present, so could be a good way to define restrictions of this type (we could even extend it to collections later). If the similarity is too close then:
>>>> 
>>>> 	let values:(Int[4]) = (1,2,3,4)
>>>> 
>>>> Could work too? Just some alternatives anyway, as I like the idea.
>>> 
>>> This kind of syntax doesn't compose well with other type productions. If you parse Int[N][M] naively as (Int[N])[M], then you end up with an array of M (array of N (Int)), which ends up subscripting in the opposite order, array[0..<M][0..<N]. C works around this by flipping the order of multiple array indices in a type declaration, so int [n][m] is really (int [m]) [n], but this doesn't work well for Swift, which has other postfix type productions—how would Int[N]?[M] parse? Choosing a prefix notation for fixed-sized array bounds is better IMO to avoid these pitfalls.
>>> 
>>> -Joe
>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160128/56f1e12c/attachment-0001.html>