Conform TokenSyntax to ExpressibleByStringLiteral and ExpressibleByStringInterpolation

[fwcd]

As mentioned in #506 (comment), we are using TokenSyntax.identifier quite a lot in SwiftSyntaxBuilderGeneration.

This PR therefore conforms TokenSyntax to ExpressibleByStringLiteral and ExpressibleByStringInterpolation, thereby making the use site more concise. This is also consistent with how we can use Strings to express many identifier-like nodes (see StringConvenienceInitializers).

Previously:

FunctionDecl(
  identifier: .identifier("xyz")
)

Now:

FunctionDecl(
  identifier: "xyz"
)

Since the .identifier function still exists, this should be a fully backwards-compatible change.

[fwcd]

@swift-ci please test

[ahoppen]

We have had this idea before and decided against it at the time and I think that argument still holds: #295 (comment)

What do you think?

[fwcd]

Hm, I see your point. In my (limited) experience though, I think there is value in making the common case easy to express. The syntax builder DSL reads a lot better IMO, in many cases there is also an argument label that already states that the syntax is an identifier, so having to include .identifier in some places while being able to omit it in others feels a bit verbose. Being able to express identifiers by string literals here feels consistent to me since we already convert strings to identifiers implicitly in a bunch of other places, like expressions. Therefore I would argue that "privileging" identifiers for this sugar would be fine, for all other use cases the existing ways of constructing TokenSyntax could be used. But, since this mostly a quality-of-life change, if you disagree, I would be fine with keeping everything as-is too.

[ahoppen]

I think this is mostly what I’m worried about. Technically, == should never have been an identifier but .spacedBinaryOperator("=="). This doesn’t really matter if all you do with the syntax tree is print it but e.g. a formatter might care about the distinction.

It’s not the most pretty solution but what do you think about the following: We introduce a new type IdentifierToken and use that as a parameter for all syntax children that have type IdentifierToken

struct IdentifierToken: ExpressibleByStringLiteral {
  let token: TokenSyntax

  init(_ token: TokenSyntax) {
    assert(token.tokenKind == .identifier)
    self.token = token
  }
  
  // If necessary, also add these
  func withLeadingTrivia(_ leadingTrivia: Trivia) -> IdentifierToken { /* … */ }
  func withTrailingTrivia(_ trailing: Trivia) -> IdentifierToken { /* … */ }
}

That would cover the common case of just passing in a string for the identifier. Using any of the functions that are defined on TokenSyntax becomes a little harder because you first need to create TokenSyntax.identifier, then modify it and wrap it in IdentifierToken, but maybe that’s not a big issue in practice.

[fwcd]

Oh, yeah, we should fix that test.

I like the idea of statically encoding where we expect an identifier. The only thing I could think about is that there are a few places (like argument labels) where also other tokens like .wildcard are 'allowed', but perhaps it would be fine to keep TokenSyntax in these places to make this explicit at the use site.

[fwcd]

So I have experimented a bit with this idea over here, unfortunately fewer nodes than I expected are pure/arbitrary identifiers. Most prominently, FunctionDecl still has to take a TokenSyntax since it could e.g. represent a operator too. Since the vast majority of uses (at least in the test suite and among the SwiftSyntaxBuilderGeneration templates is FunctionDecl identifiers, I don't think such a workaround would be worth the hassle for now.

Perhaps we could just add a convenience initializer for FunctionDecl that takes a String parameter? It feels like there ought to be some more general solution, but apart from providing an ExpressibleAsStringLiteral conformance on TokenSyntax directly, I don't really see how we could provide this sugar without disproportionally complicating some other part of SwiftSyntaxBuilder.

[fwcd]

Since we decided to defer this, I'll close this PR.