Adds explicit overload for `ExpressibleByStringLiteral` syntax types
Description
Nowadays we have DeclSyntax, ExprSyntax, StmtSyntax, TokenSyntax, TypeSyntax... with ExpressibleByStringLiteral conformance. If an initializer takes a concrete-typed parameter of one of these types, string literal syntax works perfectly, reducing lots of boilerplate codes.
However, for initializers with generic parameters like <E: ExprSyntaxProtocol>, such syntax won't work and we need to explicitly express out ExprSyntax("...") or "..." as ExprSyntax. Adding an overload with concrete type ExprSyntax can solve the problem, making SwiftSyntaxBuilder easier to use.
rdar://107787687
We have talked about this before and at some point decided that the overhead of duplicating every initializer was not worth the API improvement because in my opinion having to write ExprSyntax("...") is not toooo bad.
I am happy to re-consider this but there always needs to be a balance between the size of SwiftSyntax’s API surface and the improvements they provide for clients.
@ahoppen Do you think something like .expr(…), .text(…), .source(…)… would be slightly better?
I don’t think that’s would be a huge improvement. It would be yet another paradigm a adopter needs to learn with very marginal improvement in terms of characters.
I opened up a discussion to see if there’s some way to resolve the problem. I don’t mind ExprSyntax(…) either, but allowing literal somewhere and disallowing somewhere else looks weird and makes source breaking easier.