62 introduced the @AccountKey and @KeyEntry macros to simplify the process of defining new account keys. Some account keys need more flexibility and adopt the ComputedKnowledgeSource or OptionalComputedKnowledgeSource protocol.
This can currently done by manually declaring a manual conformance using an extension. However, that exposes the internal name of the generated AccountKey implementation.
Introduce a more refined approach to introduce this conformance. This is not trivial as Macros generally cannot introduce extensions. However, you can create an attached extension macro (attaching a macro to a type that declares an extension to a protocol). A possible design could look like this.
Create an attached extension macro (e.g., @ComputedKeyExtension). This macro is placed by the @AccountKey macro onto the generated AccountKey type. The @ComputedKeyExtension macro receives a closure that is executed in the compute implementation. It doesn't need to be generic, as it is strongly typed to the AccountStorage.
How the @AccountKey macro decides to generate the additional macro might need some experimentation what works best. Maybe as an additional trailing closure (maybe a bit weird?). Maybe we can also add another macro to the property that the @AccountKey macro could parse, however, this might not be allowed by the Swift macro system.
Additional context
No response
Code of Conduct
[X] I agree to follow this project's Code of Conduct and Contributing Guidelines
Problem
62 introduced the
@AccountKeyand@KeyEntrymacros to simplify the process of defining new account keys. Some account keys need more flexibility and adopt theComputedKnowledgeSourceorOptionalComputedKnowledgeSourceprotocol.This can currently done by manually declaring a manual conformance using an extension. However, that exposes the internal name of the generated
AccountKeyimplementation.Here is an example how such a conformance currently looks like for the
userIdkey: https://github.com/StanfordSpezi/SpeziAccount/blob/6b38140b2404146412f3a761491f29ec4acf66cb/Sources/SpeziAccount/AccountValue/Keys/UserIdKey.swift#L142-L152Solution
Introduce a more refined approach to introduce this conformance. This is not trivial as Macros generally cannot introduce extensions. However, you can create an attached extension macro (attaching a macro to a type that declares an extension to a protocol). A possible design could look like this.
Create an attached extension macro (e.g.,
@ComputedKeyExtension). This macro is placed by the@AccountKeymacro onto the generated AccountKey type. The@ComputedKeyExtensionmacro receives a closure that is executed in thecomputeimplementation. It doesn't need to be generic, as it is strongly typed to theAccountStorage. How the@AccountKeymacro decides to generate the additional macro might need some experimentation what works best. Maybe as an additional trailing closure (maybe a bit weird?). Maybe we can also add another macro to the property that the@AccountKeymacro could parse, however, this might not be allowed by the Swift macro system.Additional context
No response
Code of Conduct