Yeah, I think Holly’s post does a good job of showing both sides of the coin and has left me feeling more conflicted than I was initially. Unfortunately I can’t think of a good way to handle the fact that plural/singular is clearly the more natural choice depending on the context in which you use the identifier, other than allowing users to introduce arbitrary synonyms for pack values/types, e.g.:
func f<Element(Elements)...>(element(elements): Element...) where Element: Comparable {
for element in elements... { ... }
}
I wonder if what’s going wrong here isn’t that sequences
is misnamed, but that the .
here looks like just a normal member access when it’s really a sort of projection operation over the pack.
I could imagine us requiring a different syntax here, so that rather than sequences.count
you’d write sequences->count
or something.
Of course, doing something specific for member accesses does nothing to address the fact that sequences
is unusual as an expression value, not just as the base of a member access. I think this is a discomfort I have with the pattern expansion syntax as-proposed, beyond the use of …
. Even if you know you’re dealing with a pack expansion plan ellipsis, it won’t necessarily be obvious what is getting expanded because the pack looks like a normal identifier.
Perhaps that suggests something like the following would be good:
{sequences}.count...
This would make it clear that sequences
is a pack we’re expanding rather than a normal expression value, and it would also make the pack easier to find inside a complex expansion pattern.
ETA: Since my phone insists on correcting ...
to a unicode ellipsis character, here's a proposal: ...
retains its current meaning an we use U+2026 …
for variadic generics.