<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div>On Aug 2, 2017, at 21:39, Daryle Walker <<a href="mailto:darylew@mac.com">darylew@mac.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div><blockquote type="cite" class=""><div class="">On Aug 1, 2017, at 9:56 AM, Daryle Walker <<a href="mailto:darylew@mac.com" class="">darylew@mac.com</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=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 31, 2017, at 10:38 PM, David Sweeris <<a href="mailto:davesweeris@mac.com" class="">davesweeris@mac.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class="">On Jul 31, 2017, at 7:23 PM, 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="">The tuple will be a bunch of “T,” but the count mechanically added depends on compiler-visible number N. Well, since this is part of a proposal that already mutates the language, I thought why not add a primitive operation by fiat:</div><div class=""><br class=""></div><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class=""><font face="Monaco" class="">func tuple<T, N: Int>(from: [N; T]) -> ( #dup(N; T) )</font></div></blockquote><div class=""><br class=""></div><div class="">where “#dup” dumps a comma-separated list repeating the right-side entity with a multiplicity of the left-side value. The left-side value has to be a compiler constant expression. I was going to have the right side be an arbitrary token sequence, but I think it’s better for now to limit it to either a type (or similar) or an expression. Obviously, the receiver has to compatible with whatever being dumped there.</div></div></div></blockquote><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">We've been talking about adding Variadic Generic Parameters for a while, and I'm pretty sure that the functionality you're suggesting here would be a subset of that. We're just waiting for it to come into scope.</div></div></blockquote><br class=""></div><div class="">I don’t think this functionality is covered by variadic generic parameters.</div></div></div></blockquote></div><br class=""><div class="">After a few hours, I figured out what was bugging me. Variadic generic parameters, and the existing variadic function parameters, CONSUME arbitrarily long comma-separated lists. The #dup facility PRODUCES those kinds of lists. The features are duals, not the same. The features can synergize.</div><div><blockquote type="cite" class=""></blockquote></div></div></blockquote><br><div>Ah, ok, I see what you're saying now... I hadn't considered that the as-yet-hypothetical VGP proposal wouldn't allow for both consuming and producing VGP lists.</div><div><br></div><div>- Dave Sweeris</div></body></html>