The naming rule "API" prevents me from adding a name "Api"

[lutes1]

We have a convention in our project that the apis are named like "NameApi" and the protocol is "NameApiProtocol".

It is not possible to implement at the moment with Papyrus since there is a suffix naming rule that dictates that the type name should end with "API".

If there isn't a solid reason to keep the API suffix rule, can we get rid of it? (Or maybe add "Api" as well)

[joshuawright11]

Thanks for the feedback @lutes1!

So the ability to have custom names was actually implemented however, during the Xcode 15 betas, the Swift team removed the ability for macros to generate types with arbitrary names 🙁. Now, macros can only generate type names with pre-defined suffixes, in this case API.

What I'd really like to do is remove the generated type altogether and just provide a private instance of the protocol via the provider. This way, the namespace isn't polluted with a bunch of similar types. Not possible now, but hopefully someday.

e.g.

// How things are now
let provider = Provider(...)
let github: GitHub = GitHubAPI(provider: provider)

// How I'd like things to be once macros allow extensions of arbitrary types (`Provider` in the case of Papyrus)
let provider = Provider(...)
let github: GitHub = provider.provide(GitHub.self)

However, in the meantime I just pushed a small change (v0.6.4) so that APIMacro and MockMacro will generate a type suffixed with whatever the attribute name is.

This means you can now define your own macro with your own suffix. You're still limited by having to suffix the protocol name instead of providing whatever you want, but hopefully it's a good stopgap.

In your case, it would look defining a custom macro and using that custom macro instead of @API:

// define this new attribute in your code somewhere
@attached(peer, names: suffixed(Api))
public macro Api() = #externalMacro(module: "PapyrusPlugin", type: "APIMacro")

@Api // generates NameApi
protocol Name { ... }

[lutes1]

Got it, thank you!

[joshuawright11]

In the meantime - I'll leave this discussion open until Swift supports either:

1. Generating arbitrary type names
2. Hiding the implementation type altogether