Update CodeGeneration to use new convenience initializers

[ahoppen]

Update CodeGeneration to take advantage of #1012

[fwcd]

One minor comment, otherwise I'd say this looks good!

[fwcd]

Any reason not to use the parsing initializer here too, i.e. something along the lines of

StructDecl("@resultBuilder public struct \(type.syntaxKind)Builder") {
  ...
}

[ahoppen]

Thanks, I just missed that.

[evnik]

TBH I don't like where does it go with that new feature. Instead of clear calls structure it now just bunch of interpolated strings. Why bother with different statements if it could be just several strings for the whole file, like writeToFile("import Foundation\nclass \(className) { func \(funcName)() { } }")

[ahoppen]

TBH I don't like where does it go with that new feature. Instead of clear calls structure it now just bunch of interpolated strings. Why bother with different statements if it could be just several strings for the whole file, like writeToFile("import Foundation\nclass \(className) { func \(funcName)() { } }")

That’s very interesting because I very much prefer the new design because it’s IMO a lot easier to read. My idea for SwiftSyntaxBuilder currently was that you use the parser integration (aka string literals) for all the boilerplate that is mostly statically known while still being able to use result builder and the tree structure of the SwiftSyntax tree to

• stamp out loops and
• implement complex code generation where e.g. one node gets wrapped in another.

But that’s just my take. Going back to the example that @fwcd pointed out above, did you prefer

    StructDecl(
      attributes: [.customAttribute(CustomAttribute(trailingTrivia: .newline, attributeName: Type("resultBuilder")))],
      modifiers: [DeclModifier(name: .public)],
      identifier: "\(type.syntaxKind)Builder") {

over

StructDecl("@resultBuilder public struct \(type.syntaxKind)Builder") {

If yes, I would be very interested to hear the reasons.

[ahoppen]

@swift-ci Please test

[fwcd]

I can kind of see the point of @evnik, we're basically trading compile-time type-safety (to a degree) for convenience/conciseness/readability. E.g. things like FunctionDecl("let x = 4") will now error at run-time first, rather than at compile-time. For this particular application this is probably fine, since we usually run the generator in tandem with compilation, but it does e.g. have the IDE catch fewer errors. The advantage over plain copy-pasting is that the parser will still catch syntax errors earlier than in the generated file (I think?), but I agree that it feels a bit less "structured" than before.

[ahoppen]

That is correct, we are trading some of the compile-time safety for generation-time safety (the parser will catch the same kind of issues that would previously have been caught while compiling the generation files but as @fwcd mentioned you very rarely compile the generation files without running them, so I think it doesn’t actually make a huge difference.

IMO the real benefits of the new APIs are that

1. You can copy paste methods templates from a normal Swift file into a generation template
2. You don’t need to know the entire structure of the syntax tree for structures that are usually static (like variable initializers)
3. It’s also a lot easier to understand what’s being generated IMO because the information is denser.

[ahoppen]

Since this is “just” the update of CodeGeneration for an API that already exists, I’m going to merge. I would still like to continue the discussion.