[SE-0407] [Macros] Provide member macros with information about "missing" conformances #68372
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hborla
approved these changes
Sep 7, 2023
…ormances
Provide member macros with similar information about conformances to
what extension macros receive, allowing member macros to document
which conformances they care about (e.g., Decodable) and then
receiving the list of conformances that aren't already available for
the type in question. For example, a macro such as
@attached(member, conformances: Decodable, Encodable, names:
named(init(from:), encode(to:)))
macro Codable() = ...
Expanded on a type that is not already Decodable/Encodable would be
provided with Decodable and Encodable (via the new
`missingConformancesTo:` argument to the macro implementation) when
the type itself does not conform to those types.
Member macros still cannot produce conformances, so this is likely to
be used in conjunction with extension macros most of the time. The
extension macro declares the conformance, and can also declare any
members that shouldn't be part of the primary type definition---such
as initializers that shouldn't suppress the memberwise initializer. On
the other hand, the member macro will need to define any members that
must be in the primary definition, such as required initializers,
members that must be overridable by subclasses, and stored properties.
Codable synthesis is an example that benefits from member macros with
conformances, because for classes it wants to introduce a required
initializer for decoding and an overridable encode operation, and
these must be members of the nominal type itself. Specifically, the
`Codable` macro above is likely to have two attached member roles:
@attached(member, conformances: Decodable, Encodable, names:
named(init(from:), encode(to:)))
@attached(extension, conformances: Decodable, Encodable, names:
named(init(from:), encode(to:)))
macro Codable() = ...
where the "extension" role is responsible for defining the conformance
(always), and the "member" creates the appropriate members for classes
(`init` vs. `required init`).
Tracked by rdar://112532829.
DougGregor
force-pushed
the
member-macro-conformances-5.9
branch
from
e0facd2 to
61a975c
Compare
|
@swift-ci please test |
|
@swift-ci please test Windows |
|
@swift-ci please test Windows |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Provide member macros with similar information about conformances to what extension macros receive, allowing member macros to document which conformances they care about (e.g., Decodable) and then receiving the list of conformances that aren't already available for the type in question. For example, a macro such as
Expanded on a type that is not already Decodable/Encodable would be provided with Decodable and Encodable (via the new
missingConformancesTo:argument to the macro implementation) when the type itself does not conform to those types.Member macros still cannot produce conformances, so this is likely to be used in conjunction with extension macros most of the time. The extension macro declares the conformance, and can also declare any members that shouldn't be part of the primary type definition---such as initializers that shouldn't suppress the memberwise initializer. On the other hand, the member macro will need to define any members that must be in the primary definition, such as required initializers, members that must be overridable by subclasses, and stored properties.
Codable synthesis is an example that benefits from member macros with conformances, because for classes it wants to introduce a required initializer for decoding and an overridable encode operation, and these must be members of the nominal type itself. Specifically, the
Codablemacro above is likely to have two attached member roles:where the "extension" role is responsible for defining the conformance (always), and the "member" creates the appropriate members for classes (
initvs.required init).Tracked by rdar://112532829. Cherry-picked from #67758