-
Notifications
You must be signed in to change notification settings - Fork 441
Remove the typealiases in SwiftSyntaxBuilder that refer to syntax nodes without the Syntax
suffix
#1183
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.
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
Remove the typealiases in SwiftSyntaxBuilder that refer to syntax nodes without the Syntax
suffix
#1183
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
It have always confused me with the typealias
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, thanks Alex!
d2b895d
to
a6ee7e3
Compare
@swift-ci Please test |
a6ee7e3
to
3c7b226
Compare
@swift-ci Please test |
3c7b226
to
9989334
Compare
@swift-ci Please test |
9989334
to
b6bd54a
Compare
@swift-ci Please test |
b6bd54a
to
3161a4e
Compare
@swift-ci Please test |
…es without the `Syntax` suffix In the past, before SwiftSyntaxBuilder shared the same syntax nodes with SwiftSyntax, it made sense for it to have its own syntax nodes and thus drop the `Syntax` suffix. But since SwiftSyntaxBuilder is now just providing convenience initializers, it’s confusing to have two names to refer to the same type - the style was already pretty inconsitent in this code base. To make things consistent, drop the typealiases.
3161a4e
to
6df9357
Compare
@swift-ci Please test |
swiftlang#1183 and swiftlang#1218 raced to create a build failure.
In the past, before SwiftSyntaxBuilder shared the same syntax nodes with SwiftSyntax, it made sense for it to have its own syntax nodes and thus drop the
Syntax
suffix.But since SwiftSyntaxBuilder is now just providing convenience initializers, it’s confusing to have two names to refer to the same type - the style was already pretty inconsitent in this code base. To make things consistent, drop the typealiases.