<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">I would expect that `0` would not be allowed for type declarations.</div><div class=""><br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 28, 2016, at 9:32 PM, Félix Cloutier <<a href="mailto:felixcca@yahoo.ca" class="">felixcca@yahoo.ca</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">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.<br class=""><div class="">
<br class="Apple-interchange-newline"><span style="font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Félix</span>
</div>
<br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 28 janv. 2016 à 22:12:29, Justin Kolb via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">let values: (4:Int)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On Jan 28, 2016, at 9:04 PM, Trent Nadeau <<a href="mailto:tanadeau@gmail.com" class="">tanadeau@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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.</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Jan 28, 2016 at 8:07 PM, Erica Sadun via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">I find </div><div class=""><br class=""></div><div class=""><div class=""><font face="Menlo" class="">let values: (4 x Int) = (1, 2, 3, 4)</font></div></div><div class=""><br class=""></div><div class="">to be adequately cromulent. I believe this approach to be:</div><div class=""><br class=""></div><div class="">* Readable, even to someone unfamiliar with the syntax</div><div class="">* The parens before the assignment suggest something to do with tuples, and the numbers match the arity after the assignment</div><div class="">* The type is preserved in-place</div><div class="">* It's compact, elegant, simple</div><span class="HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div><br class=""></font></span><div class=""><blockquote type="cite" class=""><div class=""><div class="h5"><div class="">On Jan 28, 2016, at 5:56 PM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""></div></div><div class=""><div class=""><div class="h5"><div style="word-wrap:break-word" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 28, 2016, at 4:04 PM, Haravikk <<a href="mailto:e-mail@haravikk.me" target="_blank" class="">e-mail@haravikk.me</a>> wrote:</div><br class=""><div class=""><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On 28 Jan 2016, at 22:37, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><br class=""><blockquote type="cite" class="">On Jan 28, 2016, at 2:36 PM, Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com" target="_blank" class="">jtbandes@gmail.com</a>> wrote:<br class=""><br class="">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).<br class=""><br class="">Maybe we could take advantage of something which would be very invalid under the current grammar, namely (n T) rather than (n * T):<br class=""><br class=""> let values: (4 Int) = (1, 2, 3, 4)<br class=""></blockquote><br class="">Sure, or we could lift (4 x Int) from LLVM IR's syntax.</div></blockquote><br class=""></div><div class="">How about:</div><div class=""><br class=""></div><div class=""><span style="white-space:pre-wrap" class=""> </span><font face="Monaco" class="">let values:Int[4] = (1,2,3,4)</font></div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><span style="white-space:pre-wrap" class=""> </span><font face="Monaco" class="">let values:(Int[4]) = (1,2,3,4)</font></div><div class=""><br class=""></div><div class="">Could work too? Just some alternatives anyway, as I like the idea.</div></div></div></blockquote></div><br class=""><div class="">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.</div><div class=""><br class=""></div><div class="">-Joe</div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></div><span class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></span></div></blockquote></div><br class=""></div><br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature">Trent Nadeau</div>
</div>
</div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></body></html>