[swift-evolution] Strings in Swift 4
dgregor at apple.com
Wed Jan 25 23:49:55 CST 2017
> On Jan 25, 2017, at 5:49 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>> On Jan 25, 2017, at 1:10 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
>> 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.
[*] There’s one ambiguity, but it was easily addressed.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution