<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 Jul 31, 2017, at 7:23 PM, Daryle Walker via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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="">When coming up with new array interfaces, I had some array to/from tuple conversion functions:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Monaco" class="">func array&lt;T, U…&gt;(from: (T, …U)) -&gt; [1 + #countOf(U) ; T] allwhere U == T</font></div></blockquote><div class=""><br class=""></div><div class="">The problem is going the other way:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Monaco" class="">func tuple&lt;T, N: Int&gt;(from: [N; T]) -&gt; ???</font></div></blockquote><div class=""><br class=""></div><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 style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Monaco" class="">func tuple&lt;T, N: Int&gt;(from: [N; T]) -&gt; ( #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 class=""><br class=""></div><div class="">…</div><div class=""><br class=""></div><div class="">Could we do better than simple repetition? What if we define a “$$n” unit, where “n” is a nonnegative integer. For each comma-separated item, the unit will be replaced by increasing compiler-constant integers from zero. If using an expression, maybe you can call a function on the double-dollar value to get your own custom values there. This can be expanded to types once value-based generic parameters get added.</div><div class=""><br class=""></div><div class="">When there are nested #dup calls, the double-dollar unit refers to the counter for the innermost #dup. Maybe there can be a triple-dollar unit for the immediately enclosing #dup. Even quadruple- or more-dollar units for the outer levels. (Hopefully, nothing more that one level would be needed.)</div><div class=""><br class=""></div><div class="">…</div><div class=""><br class=""></div><div class="">Later, I remembered the "( 6 * TupleMemberType )” syntax for repeating a type within a tuple that's sometimes suggested. The #dup facility can be seen as a generalized version of that quasi-array-specific idea.</div></div></div></blockquote><br class=""></div><div>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><br class=""></div><div>- Dave Sweeris</div></body></html>