SE-0389: Attached Macros

[hborla (Holly Borla)]

@ksluder

If @attached is only valid when applied to a macro declaration, why is it not spelled macro(attached)?

This came up in the first review of SE-0283:

@Douglas_Gregor

Swift is consistent about having introducers (func, var, struct, protocol, etc.) be followed directly by the name of the thing being introduced. I think that's for good reason---if we put more between the introducer and the name, it's hard to find the name:

macro(expression) stringify(...)
macro(declaration(.peer, namePrefixes: ["_", "$"])) myLazy(...)

it gets hard to scan through the parenthesized bits to get to the name of the macro we're declaring. I think we're also boxed in a bit here by source compatibility---the @ from attributes gives us the ability to add new syntax without breaking existing code, but something like this:

macro(declaration(.peer, namePrefixes: ["_", "$"]))
myLazy(...)

is well-formed code today, and we shouldn't break that.

@ksluder

Every builtin attribute is a potential clash with a builder, property wrapper, or now macro. Since macros are poised to subsume the functionality of these other features, they represent something of a “terminal evolution state”, and I think it’s worth thinking ahead to avoid a situation like ISO C’s arcane rules about reserved symbol names.

This hasn't really been a problem in practice with type-based custom attributes because of the capitalization in the naming convention for nominal types. Perhaps we should recommend the same naming convention for attached macros.

@ksluder

Thinking back to the old operator syntax in which precedence and associativity were declared as members:

macro SomeMacro {
  attached(member, names: foo, *)
}

This is an interesting idea, but I think the attributed model is the right way to think about macro roles. If anything, I think macro declarations could express their overloads as "member" declarations, e.g.:

@attached(member, ...)
macro SomeMacro {
  // each 'init' declaration describes the parameters that can be used in the macro attribute

  init(_: Int) = #externalMacro(/*some external macro*/)

  init(_ : Double) = #externalMacro(/*some other external macro*/)
}

This model would allow the compiler to resolve macros to a macro declaration without performing overload resolution, but this is orthogonal to your comments about macro roles.

@ksluder

I also slipped in a proposed tweak to the name syntax. By using * for arbitrary, analogously to @available, the need for named() is hopefully eliminated.

This does not cover overloaded, prefixed and suffixed. I don't think we can eliminate named.