The macro does nothing - it's purely for decoration so a different macro can detect what code to generate.
It seems like no other macro types work either - Is this intended behavior? If not, can we remove this restriction? Since @propertyWrappers are not available on protocol functions, if this error is permanent it seems like the end of the line for this library.
From outside, that seems like a correct error for accessors macros, but a good argument for “arbitrary declaration or type macro that is known by the compiler to expand to nothing”.
There is no existing macro role that makes sense to apply to function parameters. I think we should have such a macro, but it should be a new kind of macro role -- either one that explicitly does nothing like Jordan suggests, or some other kind of macro role that's conceptually similar to a peer macro but generates peers inside the function body (which would also allow mimicking property wrappers attached to function arguments). Perhaps this should be explored in the pitch discussion for function body macros.
Thanks for the explanation @hborla! I went ahead and posted in that thread.
Out of curiosity are you aware of any workaround to annotate a protocol function parameter for the given use case? It would be awesome to get the library working for when 5.9 is released in a few weeks - but I also understand if it isn't feasible until a future release - tons of great new stuff in 5.9 already
Ah, sorry I had forgotten you mentioned that exact workaround in the original post since this is a protocol requirement! I don’t know of any workaround that allows you to write a custom attribute on a parameter of a protocol requirement.
If you'd like to provide the parameter annotation functionality now under a different syntax, you could use a typealias instead of a custom attribute for the parameter type, e.g.
typealias Path<T> = T
// in the protocol
func createTag(id: Path<Int>) async throws
And your macro can look at the type annotation for the parameter. You could deprecate the typealias once the custom attribute syntax becomes available. That's the only option I can think of.