> On Aug 2, 2017, at 21:39, Daryle Walker <[email protected]> wrote:
>
>>> On Aug 1, 2017, at 9:56 AM, Daryle Walker <[email protected]> wrote:
>>>
>>>> On Jul 31, 2017, at 10:38 PM, David Sweeris <[email protected]> wrote:
>>>>
>>>> On Jul 31, 2017, at 7:23 PM, Daryle Walker via swift-evolution
>>>> <[email protected]> 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.
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.
- Dave Sweeris
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
