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

[Justin Kolb]

That is good to hear as it should be easier to implement this feature then. I didn’t realize yet that C structs with arrays were imported like that, it helps me with the decision to settle with option 2 for now in the code I was planning to write.

I would expect that `0` would not be allowed for type declarations.


> On Jan 28, 2016, at 9:32 PM, Félix Cloutier <felixcca at yahoo.ca> wrote:
> 
> Currently, arrays contained in C structures are exported as tuples to Swift. If tuples need magic to align like C arrays, that magic already exists. Operators can't appear inside a type, so I don't think that it would be a problem to reuse * there either.
> 
> Aesthetically speaking, I think that (N x Type) looks better than (N * Type), but I don't like that (0xBeef) is either a tuple of 0 Beef objects or a hex number, which would be a problem if Swift must allow integers a type parameters.
> 
> Félix
> 
>> Le 28 janv. 2016 à 22:12:29, Justin Kolb via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>> 
>> I’m not sure I like the fact that they would be associated with tuples. As far as I’m aware tuples don’t have a public or well documented memory layout and most likely it would be better to keep them that way. To be compatible with C a fixed size array would have to have similar memory layout requirements. Also I assume there was a reason not to allow subscripting of tuples originally and adding it to something similar might confuse things. If any of these things are non-issues then I’m fine with them looking like tuples. I do think they will need to be able to be initialized with array like initializers in some form.
>> 
>> I somewhat wish they would have been added in originally as it seems like it will be trickier to find a good form that isn’t already taken. I think it would probably be problematic for the parser to make use of `*` or `x`. Maybe after moving the count to the front of the declaration `:` would end up being different enough from other uses of `:` to make this work:
>> 
>> let values: (4:Int)
>> 
>> 
>>> On Jan 28, 2016, at 9:04 PM, Trent Nadeau <tanadeau at gmail.com <mailto:tanadeau at gmail.com>> wrote:
>>> 
>>> That looks great except that I would prefer (4 * Int). Having "x" as an operator looks very odd to me, and it doesn't fit with the rest of the language.
>>> 
>>> On Thu, Jan 28, 2016 at 8: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
>>> 
>>> -- 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>
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Trent Nadeau
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> 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/a8598a5d/attachment.html>