> On Jan 25, 2017, at 5:49 PM, Chris Lattner via swift-evolution
> <[email protected]> wrote:
>
>
>> On Jan 25, 2017, at 1:10 PM, Dave Abrahams via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>> I also prefer #1. It’s a shame that this conflicts with the potential
>>> syntax for variadic generics. Is there really no way around this?
>>> I’m showing my ignorance on compilers here, but couldn’t the fact that
>>> variadic generics will be inside angle brackets be used to
>>> distinguish?
>>
>> The variadic use cases don't always have ... appearing inside angle
>> brackets. See “pack expansion” at
>> http://en.cppreference.com/w/cpp/language/parameter_pack
>> <http://en.cppreference.com/w/cpp/language/parameter_pack>
>> for example.
>
> AFAIK, we have no serious / concrete design proposal for variadic generics,
> so it remains unclear to me that we would syntactically follow the C++ model.
> The C++ model seems very influenced by its instantiation based approach.
This aspect of the C++ model of variadic generics (variadic templates) is not
influenced by the instantiation-based approach. The “…” suffix meaning “expand
this pattern for each element in the parameter packs” was a concise syntax
using an existing C++ token (…) that didn’t have any grammatical ambiguities
[*] and composed well with constrained generics. I do think the model
translates well to Swift, but obviously it’s not the only model we should
consider.
> In any case, it seems like an obviously good tradeoff to make the syntax for
> variadic generics more complicated if it makes one sided ranges more
> beautiful.
Given that we have “…” already as a binary operator for ranges, it would
probably be confusing for a “…” postfix operator to mean something totally
different than “a range without a specified end point”, even if “…” as a
postfix operator is pointless (i.e., means the same thing as “..<“).
Frankly, I still think it was a mistake to introduce “…” as a binary operator
for ranges, because closed ranges aren’t useful enough to burn an operator that
was *already* overloaded with variadic functions.
- Doug
[*] There’s one ambiguity, but it was easily addressed._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
