<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=""><div class="">There are other alternatives that don't use generics. Last time this came around, the straw man syntax was (4 x Int), and it was merely to be a shorthand for (Int, Int, Int, Int).</div><div class=""><br class=""></div><div class="">Every non-existing feature that needs to be implemented to make fixed-size arrays work are a drag. I've said it before and I'll say it again: major features that this proposal wants to rely on should be brought independently and discussed on their own. There are real problems with monolithic proposals:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">They couple independent features in an all-or-nothing basket</li><li class="">They consume a huge amount of review and design energy</li><li class="">They force sub-features to be viewed through the telescope aimed at the main feature, and make it easier to miss problems or opportunities in the big pictures</li></ul><div class=""><br class=""></div></div><div class="">The last point is especially worrying to me because things like non-type generic parameters are *much bigger* than fixed-size arrays. I think that it's a priority inversion to discuss non-type generic parameters as a bullet point of fixed-size arrays.</div><div class=""><br class=""></div><div class="">Félix</div><br class=""><div><blockquote type="cite" class=""><div class="">Le 24 juil. 2017 à 01:37, David Sweeris <<a href="mailto:davesweeris@mac.com" class="">davesweeris@mac.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">Which brings us I think full circle back to using literal values as generic parameters, "let fsa = FSA<Type, Count>(whateverArgs) //where `Count` is an integer literal, or some other integer value that can be determined at compile time".</div><div class=""><br class=""></div><div class="">- Dave Sweeris</div><div class=""><br class=""></div><div class="">On Jul 24, 2017, at 1:05 AM, Félix Cloutier via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div class="">It is not good enough for C interop because a design where the element count is data rather than part of the type cannot be layout-compatible with a C fixed-size array.</div><div class=""><br class=""></div><div class="">Félix</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 23 juil. 2017 à 22:22, Charles Srstka 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=""><div class="">Do FSAs really need special sugar, though? They won’t be an extremely heavily-used construct, but rather they’ll be occasionally used either for performance reasons or to interact with C APIs. Sure, C had a short syntax for making them, but making pointers in C was short, too, and that hasn’t been carried over into Swift. In fact, a FSA has a lot in common with an UnsafeBufferPointer that you don’t have to worry about deallocating. Furthermore, there are collection types such as Set and ContiguousArray which are arguably more useful than FSA, yet don’t have their own syntax.</div><div class=""><br class=""></div><div class="">Is this really not good enough?</div><div class=""><br class=""></div><div class="">let arr = FixedArray<Type>(capacity: x)</div><div class=""><br class=""></div><div class="">Charles</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 23, 2017, at 11:03 PM, Taylor Swift via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">This proposal gives FSAs their own literal syntax. You write [; 3, 5] to make a FSA, not [3, 5].<br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sun, Jul 23, 2017 at 11:54 PM, David Sweeris <span dir="ltr" class=""><<a href="mailto:davesweeris@mac.com" target="_blank" class="">davesweeris@mac.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><span class=""><div class=""><br class=""></div><div class="">On Jul 23, 2017, at 8:32 PM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" target="_blank" class="">kelvin13ma@gmail.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Sun, Jul 23, 2017 at 5:48 PM, David Sweeris <span dir="ltr" class=""><<a href="mailto:davesweeris@mac.com" target="_blank" class="">davesweeris@mac.com</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 dir="auto" class=""><span class=""><div class=""><br class=""></div><div class="">On Jul 23, 2017, at 12:18, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" target="_blank" class="">kelvin13ma@gmail.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Sun, Jul 23, 2017 at 2:21 PM, David Sweeris <span dir="ltr" class=""><<a href="mailto:davesweeris@mac.com" target="_blank" class="">davesweeris@mac.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto" class=""><div class=""><br class=""></div><div class=""><span class="m_-4281577226569470587m_-7264807722288193896gmail-">On Jul 23, 2017, at 09:08, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" target="_blank" class="">kelvin13ma@gmail.com</a>> wrote:<br class=""><br class=""></span><div class=""><span class="m_-4281577226569470587m_-7264807722288193896gmail-"><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><span class="m_-4281577226569470587m_-7264807722288193896gmail-m_-3186585211898980809gmail-im"><span style="font-family:monospace,monospace" class="">let fsa:[2 * Int] = [2 * 5, 3</span><span style="font-family:monospace,monospace" class="">] // [10, 3] ???</span></span></div></div></blockquote><div class=""><br class=""></div></span><div class="">Correct. If you wanted a multidimensional array, that'd be written "let nestedFSA: [2*[5*Int]]". Or, speculating a bit, I suppose maybe "<span style="background-color:rgba(255,255,255,0)" class="">let nestedFSA: [[5*Int]*2]", if we wanted there to be a column-major option</span>. IMHO all those read better than this proposal's syntax.</div></div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">No, what I’m saying is does the phrase “[2 * 5, 3]” mean a fixed size array of length two and with the elements 5 and 3, or a flexible sized array with two elements 10 and 3? This is v confusing and difficult to read, especially when you have actual multiplications going on such as <br class=""><br class=""></div><div class=""><span class="m_-4281577226569470587m_-7264807722288193896gmail-"><div class=""><div class=""><span class="m_-4281577226569470587m_-7264807722288193896gmail-m_-3186585211898980809gmail-im"><span style="font-family:monospace,monospace" class="">let fsa:[2 * Int] = [2 * 3 * 5, 3</span><span style="font-family:monospace,monospace" class="">] // [15, 3] ???</span></span></div></div></span></div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">That's... huh? To me, "[<span style="background-color:rgba(255,255,255,0)" class="">2 * 3 * 5, 3]" should </span>obviously evaluate to "[30, 3]". How are you getting that "[2*5*3, 3]" could be a 2-element FSA containing 15 and 3? Are you suggesting that instead of "[value * value * value, value]", it could be parsed as "[modifier value * value, value]" (with `modifier` being "2 *")? To me, that syntax would <i class="">strongly</i> suggest that the modifier only applies to the first element of the array, which would mean the only other option for parsing it would be equivalent to "[[3, 5], 3]", which is neither a match for fsa's type, nor a semantically valid array (the elements have to be the same type), nor a syntactically valid array (the nested array in the first element is missing its "[]").</div><span class=""><div class=""><br class=""></div></span></div></div></blockquote><div class=""><br class=""></div><div class="">Well, that <i class="">is</i> the syntax you’re proposing right? What comes on the left of the asterisk is the FSA dimensions, and what comes to the right is the FSA elements. </div></div></div></div></div></blockquote><div class=""><br class=""></div></span>No, the <i class="">type</i> of the FSA's elements is what comes to the right: <span style="background-color:rgba(255,255,255,0)" class="">"[count * <i class="">Type</i>]".</span> I don't recall any discussion around the value side of things, so I'd guess they would've just used the existing array literal syntax, "let fsa: [2*[2*Int]] = [[0, 1], [2, 3]]".<div class=""><div class=""><div class=""><br class=""></div><div class="">- Dave Sweeris</div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><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 dir="auto" class=""><span class=""><div class=""></div></span></div></div></blockquote></div></div></div></blockquote></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>_______________________________________________<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></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></body></html>