Using SPM 5.6 plugins to generate CasePaths?

[tgrapperon]

The latest version of SPM allows to define plugin targets and modules. These plugins can act as prebuild tools that can potentially automatically run and generate the code. For example, swift-protobuf is already capable of generating data types corresponding to some protobuf definitions in .proto files. These generated files are pre-build products and not checked out with the repository.

The discussion about Regex Literals seems to condemn the use of / as a prefix operator (or at least its convenient usage, without having to add back-ticks in the best of foreseeable outcomes). If the CasePath functionality is evoked and acknowledged by multiple core team members as some potential evolution of KeyPaths, there is no clear timeframe. This feature has already been soft-pitched in Swift Forums in the past and received very few comments by the core team (none to my knowledge, but I may have missed some as I don't know everybody). So it's probably safer to bet that / will be prohibited as prefix operator way before KeyPaths can fulfill CasePaths role.

So it seems there's a case for code-gen using SPM plugins to fill the gap in the meantime. swift-case-paths would ship with a plugin, and clients of this plugin would see their enums' CasePath's automatically generated at build time. By installing CasePaths in extensions of their enums, we would gain code completion with better inference, and a few ns when extracting them.

Fortunately, code generation of CasePath is easy once enums are extracted with their cases and associated values. To extract these enums, there are a few possibilities:

• Using some dedicated third party tool like Sourcery;
• Using swift-syntax;
• Using swift-parsing;
• Using some ad-hoc parsing.

Using Sourcery would introduce a foreign third-party dependency, which is a point of failure. swift-syntax setup is also fragile and requires matching the Swift version of the project with the one it knows, which can be inconvenient when using beta versions of Xcode. This is also a third-party library, albeit semi-official.

swift-parsing should be able to handle the task, but it imports swift-benchmarks. This wouldn't be an issue in TCA projects where this library is also imported.

The ad-hoc solution has no dependency, and parsing enums in the wild seems achievable, albeit less conveniently than with swift-parsing.

Of course, this plugin could be implemented as a third party, but I wanted to discuss the opportunity of including it in swift-case-paths directly until KeyPaths are up to the task, and what are your thoughts about the parsing question, or the whole code-gen idea using plugins in general.

[stephencelis]

@tgrapperon Thanks for taking the time to write this out.

Just so I understand, you are not suggesting generating case paths as we've done in the past, but instead you are suggesting an SPM plugin-driven transform layer that would process, for example, existing /Enum.case into CasePath(Enum.case) or something like it? If so, my main concerns here is that we'd be fighting against build tools (Xcode indentation and syntax highlighting, for example), and that we'd have a big parsing problem ahead of us, as you mentioned and which has been a big part of the evolution discussion 😅

[tgrapperon]

Thanks for the feedback @stephencelis!
I think it is similar to how you did in the past if you're referring to your enum properties episode with swift-syntax. The idea would be to achieve what Xcode is doing with CoreData or CoreML, which is generating an internal Swift source file with explicit CasePath implementations in it.

Assuming that / is not future-proof, the users will have to migrate their codebase. If we also assume that CasePath functions will be assumed by KeyPath in the future, we can guess that the final "source code" destination of /Enum.action will be \.case (or \Enum.case). This formulation is unachievable with the current version of Swift, but if we define somewhere:

extension CasePath<Enum, Void> {
  static var case: Self { .init(embed:…) }
}

we should be able to simply write .case whenever the API expects CasePath<Enum, Void>. This would bring us halfway to the final "source code" destination. When KeyPaths are finally improved, the user will only have to add \ or \Enum before their .case calls to migrate to the new key paths. The extension implementation could also use these new KeyPaths and allow the user to defer their source migration while still using the new KeyPaths internally. This is already the case with the current operator situation though.

This is a two steps migration plan unfortunately, assuming that we must change something now, but that we can't write today what it will be in the future.

So the idea would be to provide a SPM plugin that generates CasePath's boilerplate extensions automatically when the project is built like it's done with CoreData. The implementation is internal and these files are not cluttering the repository. The implementation is also automatically updated when the user updates swift-case-paths and builds its project again.

These CasePath variables should be more easily resolved by the compiler than with the current operator approach, and they would allow dropping the Enum qualifier in many cases, like it's the case with KeyPath. We can also imagine adding another reference to the implementation as

extension Enum {
  static var _case: CasePath<Self, Void> { .case }
}

With this configuration, the user will also be able to reach the CasePath using Enum._case in any non-constrained site.

There are still open questions though, like how plugins are working in modularized projects: do we need to declare the plugin for each target? If so, there are possible ways to improve the experience, but it would be inconvenient.

And there is the whole enum parsing that can be tricky in some cases, especially if nesting is involved.

I don't think that another easily reachable character is available to build a prefix operator unfortunately.
Adding back-ticks may be the way to go: the final migration could be executed with a search and replace in all files. But it would be a very clumsy solution until then. I'll experiment with a few other ideas.

[stephencelis]

Due to some of the original problems we had with code gen, we're not sure going back to it is the right direction for the library. Some of the original problems include:

• Not being able to generate case paths for enums "out of scope," which includes the standard library, apple frameworks, dependencies (especially those in static libs). There might be some fancy ways to generate all of these, but the problem feels pretty fraught, especially when you consider availability checks, platforms, etc.
• Nested enums are difficult to resolve and create case paths for.

When we moved to reflection, all of these problems went away.

So instead, I think we'd probably prefer to create a non-operator version of /: a function or initializer that takes an embed function and returns a case path. We currently have a static CasePath.case function (though we deprecated it awhile back in favor of /). If Swift 6 ships without enum key paths, we'd probably bring that back, or something like it.

[tgrapperon]

Good point about foreign types, I've missed that.
Let's hope we get KeyPath for enums in Swift 6 then, but I'm not optimistic. Maybe the heat of the discussion in Swift forums will at least make things move a little toward this direction🤞.