[Pitch] Declaration macros

[Douglas_Gregor]

@mayoff

Can a declaration macro be attached to a case declaration in an enum? For example:

enum E {
  @myMacro
  case c
}

I think that's fine, yes, although the form of AttachedDeclarationExpansion currently means you won't be able to change anything about the case.

@mayoff

Also, does an ‘outer’ macro see the expansion of an ‘inner’ macro? For example:

@outerMacro
struct S {
  @innerMacro
   var i: Int
}

As in the expression-macros proposal, macro expansion is outside-in, so @outerMacro would get expanded first. It would see the unexpanded @innerMacro on var i.

@mayoff

Suppose innerMacro adds member _i as a peer to i in S. Does outerMacro see member _i?

No, it will not.

@mayoff

Could declaration macros subsume the need for type wrappers ?

Maybe? Right now, we don't have an easy way for a macro applied to a type to add accessors to its members, but this seems like something that could fit into the model. @hborla has been thinking about this a bit and might want to weigh in.

@tgoyne

The "Up-front declarations of newly-introduced macro names only" mentions the compiler benefits from this, but I think it's also incredibly valuable for documentation purposes. A documentation generator could potentially automatically list the declarations a macro can define, and even without that just being able to command-click a macro and see that information without having to read through the actual definition of the macro helps mitigate one of the major problems which can emerge from macros.

You're absolutely right. I should incorporate this additional argument into the proposal test, thanks!

@tgoyne

Being able to fully replace the body of a function but not being able to fully replace the annotated declaration feels like a funny mismatch, but I couldn't come up with a stronger argument than that and I can see why one is more of a problem for tooling than the other.

Yeah, the ability to replace a function body does feel a bit different than the rest of the proposal. It's a really useful capability, but perhaps it should be split out into a separate proposal. Perhaps we should see how many of our interesting use cases depend on it.

@sspringer

When using a declaration macro to manipulate a function body, you might want to use a function argument of a certain type in the inserted code. So such a macro should be able to find and use such an argument, and of course the macro should then only be applicable if an according argument exists.

Sure, the macro could look into the function declaration's parameter list to find the parameter, if it's there, and use it. However, it might be hard to precisely determine that the function parameter has the precise type you want, without an extension to the macro expansion context that provides type information.

@sspringer

Inserted code should be able to exit the function, even in the general case of the function returning nothing or any (!) optional value

Inserted code will be type-checked in the same way that the originally-written code is type-checked, so you can return from a Void function, or return nil from an optional-returning function, and it's fine.

@sspringer

I have quite a few places where fixed structures are built for configuration purposes and I wonder in which cases macros could help to spare some of this build time. In the case of a struct with “simple” computed values (no references) a macro could certainly insert the computed values into the construction code, but could this go any further, e.g. already producing the resulting memory layout for the struct? What about dictionaries?

This seems more like constant initialization than macros. Perhaps we could find a way to do this with macros if they were able to add binary blobs to the resulting object file, which is something we could permit by adding more API to MacroExpansionContext. This could also be useful for implementing something like the C23 or Rust #embed.

@Alejandro_Martinez

One thing I'm not clear is in the "order of execution" inside the compiler. macros seem to run after type checking, but that means that if a macro wants to add the implementation for the requirements of a protocol, the compiler needs to type check the conforming type after macro expansion.

Right, this area is dicey, because macro expansion will occur as part of type checking. This is much of the (implementation) reason why declaration macros can only have specific, prescribed effects, and we declare them in the macro itself, so we can make sure that expanding a macro cannot invalidate a previous result.

@Alejandro_Martinez

Also seeing how the peers parameter is separated from .attached in @declaration, does that mean it can be used with .freestanding too?

Yes. Effectively, .freestanding can only have peers, since there is no way for it to have members.

@Alejandro_Martinez

I know this is not really "swift code" but it feels a bit weird, if this was Swift I would expect the peers to be an associated value of .attached.

We could do that. I'm not at all... attached... to the design of these attribute arguments.

@ktoso

I'm assuming when we declare a specific member the macro is expected to emit (like rawValue), and the macro fails to emit such, that'd be a compile error -- since the macro didn't do what it claimed. And if there's any "we may be able to make some member" then it should be using .arbitrary I suppose.

I was thinking it would be okay to overpromise in a macro declaration. In the option-set example, we shouldn't require the macro to define a rawValue if the user already wrote one, but that's the only reason I'd thought of for allowing a macro not to introduce a declaration that it said it might.

@ktoso

I wasn't entirely sure about the @declaration(.attached, members: where we attached to a variable decl. It is "members" specifically because we're emitting accessors, right? And those are "inside"

Yeah, this feels a little sketchy. We could have accessors be a separate thing entirely, which might feel cleaner.

@ktoso

Should a freestanding macro have "peers" specified or doesn't that really make sense... Say, if it's a #nice_description that makes a nice var description: String {} would that declare @declaration(.freestanding, peers: [.named("description")]) macro?

Yes, I should add an example here, because @Alejandro_Martinez had a similar question.

@ktoso

I'm a bit sad about lack of ability to modify the attached to decl (though I do see the complications it'd cause). It means we can't implement a traced function:

@traced func hello() {} // won't work; not allowed to modify the body.

Hmm. I was intending AttachedDeclarationExpansion.functionBody to be used for this purpose. Is that not enough, if it can replace the body?

Doug