> On Aug 1, 2017, at 9:56 AM, Daryle Walker <dary...@mac.com> wrote: > >> On Jul 31, 2017, at 10:38 PM, David Sweeris <daveswee...@mac.com >> <mailto:daveswee...@mac.com>> wrote: >> >>> On Jul 31, 2017, at 7:23 PM, Daryle Walker via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> 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: >>> >>> func tuple<T, N: Int>(from: [N; T]) -> ( #dup(N; T) ) >>> >>> 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. >> >> 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. > > I don’t think this functionality is covered by variadic generic parameters.
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. — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
