Skip to content

Make SyntaxToken extend ExpressibleByStringLiteral #295

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

Conversation

kimdv
Copy link
Contributor

@kimdv kimdv commented Jun 23, 2021

@ahoppen I have open a PR, so we can discuss it here.

From #291

4a. TokenSyntax should be ExpressibleByStringLiteral. That way we wouldn’t need SyntaxFactory.makeIdentifier("myFirstVar"). It might also remove the need for convenience of passing in a String for a TokenSyntax in the convinience initializers because TokenSyntax can now just be expressed by a string literal.

I'm not sure how implement this.

Because if we add ExpressibleByStringLiteral to SyntaxToken, how can it now to create a identifier token, just like when we use SyntaxFactory.makeIdentifier("myOtherVar")

@ahoppen
Copy link
Member

ahoppen commented Jun 24, 2021

Argh, I temporarily forgot that TokenSyntax nodes carry a kind. My initial idea was that let myToken: TokenSyntax = "hello" should create an identifier with the text hello. But since TokenSyntax carries a type, we need to decide whether myToken should indeed be an identifier or maybe some other token like a contextual keyword. So I take back my idea.

I also just realized that since #293 we can write

IdentifierPattern(identifier: .identifier("myOtherVar")),

instead of

IdentifierPattern(identifier: SyntaxFactory.makeIdentifier("myOtherVar")),

which I think is a very precise and short syntax for what we are trying to achieve.

@kimdv
Copy link
Contributor Author

kimdv commented Jun 24, 2021

Good. I was a bit confused. Maybe I didn't know something.

But will close then.

@kimdv kimdv closed this Jun 24, 2021
@kimdv kimdv deleted the kimdv/make-token-syntax-implement-expressible-by-string-literal branch September 5, 2021 07:27
adevress pushed a commit to adevress/swift-syntax that referenced this pull request Jan 14, 2024
…nings

Don't emit AlwaysUseLowerCamelCase for decls that `override`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants