Vision for macros in Swift

[DougGregor]

Updated and revised from the gist initially posted to the forums back in October (https://forums.swift.org/t/a-possible-vision-for-macros-in-swift/60900), reflecting improvements to the design.

[beccadax]

General thoughts:

• When you discuss conformance macros, you allude to it being possible to have a single macro declaration with multiple roles. How does this work? Is the macro only valid to apply in a place where all of its declared roles make sense? (Can a macro declaration be overloaded on role to support a disjunction of roles under the same name?) Do all of the roles have to be implemented in the same #externalMacro type, or can different roles be implemented by different types?
• Some of the role names use compiler jargon, like codeItem and witness, that I dearly hope we don’t end up using in the actual feature.
• Nit: I hope @attached(peer) gets workshopped a little more—it’s kinda strange to have it have the same name but a very different function. Or maybe there’s a unity here that I don’t understand?

[DougGregor]

@beccadax the "attached macros" proposal has a lot more detail about macro roles and what it means to inhabit several different roles. Does that address your questions/concerns? Do you feel that the discussion needs to be lifted up into the vision document?

I'm happy to workshop names like "codeItem" and "witness" a bit more.

[beccadax]

the "attached macros" proposal has a lot more detail about macro roles and what it means to inhabit several different roles. Does that address your questions/concerns?

Maybe it's subtle enough that I overlooked it, but I don't quite see the answer to my question there; you mention that a macro can have multiple roles and that the compiler expands each of them, but I don't think you talk about what happens when only some of those roles are applicable.

Let me make the question more concrete. Consider the Clamping macro described in that document:

@attached(peer, prefixed(_))
@attached(accessor)
macro Clamping<T: Comparable>(min: T, max: T) = #externalMacro(module: "MyMacros", type: "ClampingMacro")

What happens if I do this?

struct MyStruct {
    @Clamping(min: 0, max: 255) func fn() { ... }
}

Clamping has both an @attached(peer) role, which is perfectly valid to use on a method, and an @attached(accessor) role, which is only valid on a property (or subscript, I suppose). Does the Swift compiler expand the @attached(peer) role but not the @attached(accessor) role? Or does it diagnose an error because you tried to apply Clamping in a place where the @attached(accessor) role is not valid?

(ClampingMacro.expansion(of:providingPeersOf:in:) could, of course, diagnose an attempt to use it on anything but a var. For the sake of argument, assume that it doesn't. Maybe its designer wants it to apply a postcondition to the return value when it's used on a method.)

Do you feel that the discussion needs to be lifted up into the vision document?

Probably not the whole discussion, but a brief mention of what it means when a macro has multiple roles might help readers understand how different roles are supposed to be used in concert.

[DougGregor]

@beccadax we should move this discussion elsewhere. Attached macros has a pitch

Maybe it's subtle enough that I overlooked it, but I don't quite see the answer to my question there; you mention that a macro can have multiple roles and that the compiler expands each of them, but I don't think you talk about what happens when only some of those roles are applicable.

I've added a paragraph to this effect in the attached macros proposal (7add644), but I think further discussion should occur on the forums, not here.

Probably not the whole discussion, but a brief mention of what it means when a macro has multiple roles might help readers understand how different roles are supposed to be used in concert.

We have the Clamping example where a single macro inhabits multiple roles, and they are used in concert to achieve the property-wrapper effect. This seems sufficient to me. Again, I think we should continue this discussion on the forums.

[xwu]

Traced

[DougGregor]

Thanks!

[DougGregor]

The Language Workgroup has approved this vision document. Merging!