<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 23, 2017, at 3:33 PM, Robert Widmann <<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Some thoughts inline.</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class="">On Jan 21, 2017, at 11:06 AM, Daryle Walker 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 class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">1. Variadic generics</div><div class=""><br class=""></div><div class="">When I look at<span class="Apple-converted-space"> </span><a href="http://swiftdoc.org/" class="">SwiftDoc.org</a>, I see some functions repeated with differing numbers of parameters. This seems like a job for variadic templates^H^H^H^H^H^H^H^H^H generics, like in C++. Fortunately, someone has already wrote about this, at <<a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#variadic-generics" class="">https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#variadic-generics</a>>. A new idea I came up with is that both homogeneous (the current support) and heterogeneous variadic parameters can appear in function declarations. Each can appear at most once in a declaration. And they can co-exist in the same declaration; there’s no problem unless the two packs are adjacent and at least the (lexically) second one doesn’t mandate a label. In that case, and when the homogenous pack appears second, count from the lexically last argument backwards until an argument cannot be part of the homogeneous type, that’ll be the border. Count the other way when the homogenous pack is first. (It’s possible for one pack to have zero elements.)</div></div></div></blockquote><div class=""><br class=""></div><div class="">C++ has a simpler rule (for once): If you’re going to pack, you have to pack last. This is roughly the rule we have as well for argument lists in functions that don’t have labels - they can have any number of variadic parameters because we can use the argument label to guide the tuple type comparison and disambiguate. Here we lack argument labels (and I’m not sure it’s useful to have them). </div><div class=""><br class=""></div><div class="">As for the distinction between heterogeneous and homogenous lists, I’m not sure it’s a useful thing to have unless you’re trying to roll your own Tuple (which is a thing you can do now with <a href="https://github.com/typelift/Swiftz/blob/master/Sources/HList.swift" class="">HLists</a> anyway). Any type that wishes to take a variadic number of homogeneous type variables is a type that can be parametrized by one type variable and enforce the cardinality invariant elsewhere (see std::initializer_list).</div><br class=""></div></div></blockquote><div><br class=""></div><div>The “homogenous list” I’m talking about are the variadic parameters that are already in the language. And they can already be non-last in the list. (At least it compiled, but the parameter I had after it had a default value, so I don’t know if that made a difference.) The “homogenous” is to differentiate them from parameters introduced by variadic generics (which would be “heterogeneous”).</div><div><br class=""></div><div>My inspiration was from C++, where a function template can have both C++ and C variadic parameters. The C-level ones have to be last, and the C++-level ones next-to-last. Last I checked, this pattern was only useful for stupid resolution tricks; you couldn’t actually use such a function. (Using C-level variadics requires using a macro on the preceding argument. But on a dual-variadic function, this would be the C++-level variadic argument (instead of a singular one), which was (is?) not compatible with said macro.) I just want to make a generic function that uses both kinds of variadic argument lists actually usable, by defining the dividing line. Again, this is only a problem if the two lists are adjacent and the second list doesn’t have an external label.</div><div><br class=""></div><div>AFAIK, there is no concrete specification for variadic generic functions yet. Hopefully, that team will take my advice into account. IF you don’t think a heterogeneous list should be non-last, nor co-exist with homogenous list, you can bring it up then.</div><div><br class=""></div><blockquote type="cite" class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">2. More on Arrays</div><div class=""><br class=""></div></div></div></blockquote></div></blockquote>[SNIP]<br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><br class=""></div><div class="">This also doesn’t seem to fit with the rest of the language. To my mind a more correct answer is, once again C++-style, integers-in-parameter-position and a catch-all homogenous `Tuple<T, .UInt>` (more than likely, magic type alias).</div></div></div></blockquote><div><br class=""></div><div>Right now, generics can’t use non-type parameters, so any “FixedArray<Int, 6>”-like syntax is out. I feel that anonymous arrays would have a usage model mostly like tuples; hence the close syntax. I prefer a built-in type instead of a library type since we need some magic to enforce:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>strideof( ArrayType ) == Element-Count * strideof( ElementType )</div><div><br class=""></div><div>down to the extent that there shouldn't be any padding between elements of the inner non-array type (in the case of nested arrays).</div><div><br class=""></div><div>Since we anonymous and named heterogenous product types (tuples vs. structs and classes), I want the same thing for homogenous product types (array extension to tuples vs. nominal “array" type). We broke away from C in the handling of enums, why not arrays too?</div><div><br class=""></div><div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">— </div><div class="">Daryle Walker<br class="">Mac, Internet, and Video Game Junkie<br class="">darylew AT mac DOT com </div><div class=""><br class=""></div></div></div></div><div><br class=""></div></div></body></html>