Skip to content

Parse an ellipsis T... for type parameter packs #61575

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 3 commits into from
Oct 15, 2022
Merged

Parse an ellipsis T... for type parameter packs #61575

merged 3 commits into from
Oct 15, 2022

Conversation

hamishknight
Copy link
Contributor

In a generic parameter list, parse an ellipsis to produce a type parameter pack. This replaces the previous @_typeSequence attribute.

@hamishknight hamishknight mentioned this pull request Oct 14, 2022
Merged
slavapestov
slavapestov approved these changes Oct 14, 2022
View reviewed changes
Copy link
Contributor

@slavapestov slavapestov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, thank you!

@hamishknight
[AST] NFC: Refactor GenericTypeParamDecl construction
b645e63 
Add distinct overloads for the parser,
deserialization and code synthesis.
@hamishknight
Parse an ellipsis T... for type parameter packs
48ea933 
In a generic parameter list, parse an ellipsis
to produce a type parameter pack. This replaces
the previous `@_typeSequence` attribute.
@hamishknight
[AST] Remove @_typeSequence attribute
6aa44a1 
This is no longer needed now that we have the
ellipsis spelling.
@hamishknight
Copy link
Contributor Author

swiftlang/swift-syntax#948

@swift-ci please test

@hamishknight
Copy link
Contributor Author

One interesting case to consider here is whether to allow <T ...>, we actually already allow this for regular variadic parameters e.g func foo(_ x: Int ...) in addition to PackExpansionTypeRepr e.g (T ...). Should we continue to be consistent with regular variadics here, or should we reject this for pack parameters and pack expansion types?

@slavapestov
Copy link
Contributor

I think allowing a space before ... is fine and would be consistent with the rest of the language

@hamishknight hamishknight merged commit d82e748 into swiftlang:main Oct 15, 2022
@hamishknight hamishknight deleted the etc branch October 15, 2022 09:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@slavapestov slavapestov slavapestov approved these changes

@CodaFi CodaFi CodaFi approved these changes

@ahoppen ahoppen Awaiting requested review from ahoppen

@bnbarham bnbarham Awaiting requested review from bnbarham bnbarham is a code owner

@DougGregor DougGregor Awaiting requested review from DougGregor DougGregor is a code owner

@rintaro rintaro Awaiting requested review from rintaro rintaro is a code owner

@hborla hborla Awaiting requested review from hborla hborla is a code owner

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@hamishknight @slavapestov @CodaFi