[Pitch] Declaration macros

[Douglas_Gregor]

@s-k

I have a question. Would a function body with an attached macro be type-checked before the macro expansion?

That's a great question. I think all of the arguments in favor of type checking the macro arguments before expanding the macro apply to the function body just as well: better diagnostics, macros only get well-formed inputs, easier to reason about what macros do, etc.

However, your question and @Alejandro_Martinez 's question about order-of-operation bring up a really important point. Right now, the compiler will only type-check the body of the function when it needs the body for something, i.e., to generate code for the function. We don't want to pay the cost of type checking the function body if we're only doing so to expand a macro for its peer declarations.

This is yet more evidence for...

@Douglas_Gregor

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.

i.e., we should separate out the ability to add or replace a function body from the ability to add peer declarations, attributes, etc., because they run at different conceptual times: we need peer declarations to do things like name lookup, we need attributes to understand the full signature of a type for type checking, and we need the function body to generate code. This might even mean that "peer" and "member" macro implementation entry points should be separate in the design .

@s-k

And thinking about it, it would even be nicer if one could leave out the {} when declaring the function:

Right, it should be fine for a function-body-producing macro to provide a function body for a function that doesn't have one.

@stevex

This is more about reflection than macros, but there's probably some interaction there where the macro has to leave something there for reflection to find and act on so at runtime the API routing can be built from what reflection discovers.

I believe this will be achievable by having a macro generate custom metadata attributes, as pitched elsewhere.

@Alejandro_Martinez

Sorry, I’m a bit slow today , but does that mean we won’t be able to use macros to implement protocol conformances?

If we can't implement at least some protocol conformances with macros, we've gotten macros wrong. The question is how best to do it. With this pitch, you could create an attached macro that you place on the type itself, and which generates member declarations that correspond to the requirements of the protocol. That macro can use syntactic information from the type, e.g., it can walk through and find the declared properties. However, it can't reason about (e.g.) the effects of macros or property wrappers on the declared properties, so it's going to have rough edges. Perhaps that's okay, or perhaps it means we need a different model for things that want access to stored properties (protocol conformances, member wise initializers, etc.).

Doug