<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 27, 2017, at 11:55 AM, 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 dir="auto" 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;"><div class=""><br class=""><br class="">~Robert Widmann</div><div class=""><br class="">2017/01/26 13:37、Daryle Walker <<a href="mailto:darylew@mac.com" class="">darylew@mac.com</a>> のメッセージ:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><br class=""><div class=""><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 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;"><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 class=""><br class=""></div><div class="">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.)</div></div></div></blockquote><div class=""><br class=""></div><div class=""><span class="" style="background-color: rgba(255, 255, 255, 0);">A warning was just introduced if you declare non-terminal variadics without argument labels to disambiguate parameters. That's what I meant. Being able to constrain a signature so that it must have at least a certain cardinality seems useful, but what I’m saying is I’m not sure it’s useful to constrain it in multiple directions. Consider</span></div></div></div></blockquote><div><br class=""></div><div>Just checked with a Playground; it’s actually an error. But seeing this:</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="auto" 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;"><div class=""><span class="" style="background-color: rgba(255, 255, 255, 0);">struct Foo<T, U, V…, LAST> {}</span></div><div class=""><span class="" style="background-color: rgba(255, 255, 255, 0);"><br class=""></span></div><div class=""><span class="" style="background-color: rgba(255, 255, 255, 0);">which can be instantiated as Foo<String, Int, UInt, NSObject> to satisfy the requirements of the signature. Rearranging this declaration to shuffle non-variadic parameters to the front doesn’t change that</span></div><div class=""><br class=""></div><div class=""><span class="" style="background-color: rgba(255, 255, 255, 0);">struct Foo<T, U, LAST, V...> {}</span></div><div class=""><span class="" style="background-color: rgba(255, 255, 255, 0);"><br class=""></span></div><div class=""><span class="" style="background-color: rgba(255, 255, 255, 0);">It just changes the order in which you or the typechecker comes around to instantiate the signature. We’re getting down to matters of practicality here: Yes, there’s nothing stopping us from allowing variadics in any position, but what’s the point? What kinds of structures can I only model with this kind of bi-directional cardinality matching?</span></div></div></div></blockquote><div><br class=""></div><div>I’m not writing about variadic parameters within “<>”…</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="auto" 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;"><blockquote type="cite" class=""><div class=""><div class=""><div class="">The “homogenous” is to differentiate them from parameters introduced by variadic generics (which would be “heterogeneous”).</div></div></div></blockquote><div class=""><br class=""></div><div class="">Ah, so there’s not a hard difference here just a terminology change. The use of “homogenous” and “heterogeneous” here is superfluous, since it’s pretty much assumed that in a variadic setting you wish for a heterogeneous list of types. After all, by linearity, Foo<T, T, T, T…> is isomorphic to Foo<T>. </div></div></div></blockquote><div><br class=""></div><div>…but within the “()”. I think we’ve been writing at cross-purposes. I’m talking about functions like:</div><div><br class=""></div><div>func test1<...T>(myIntegers: Int…, _ myT: T…)</div><div><br class=""></div><div>or</div><div><br class=""></div><div>func test2<...T>(_ myT: T…, _ integers Int…)</div><div><br class=""></div><div>and finding the line between the “Int” list (homogenous and “()”-level) and “T” list (heterogenous and originally “<>”-level). But now I know these cases are already banned, so don’t worry about it.</div><div><br class=""></div><div>I wasn't considering homogenous arguments within “<>” (assuming variadic generics are added), since those would be a case within heterogenous arguments, as you said.</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></body></html>