SE-0382: Expression Macros

[Douglas_Gregor]

@kishikawakatsumi

Currently, however, there is very little documentation on the SwiftSyntax API or the structure of the syntax tree.
Is there any plan to organize such information for the release of macros?

and...

@s-k

I have spent quite some time using SwiftSyntax. While the package is very powerful, its developer experience is not that great. First of all, I found little useful documentation. Secondly, finding the right types or properties needed to solve a given problem often took me a lot of time and experimentation.

are great feedback, thank you. We are looking to improve the SwiftSyntax documentation, as well as providing more examples for folks to start from.

@s-k

The use of an @-attribute in @expression macro ... looks odd to me. I think the reason is that (to my knowledge) every other @-attribute is used to modify existing code and is therefore optional. You can delete @MainActor or @escaping and the remaining code is still valid. Removing @expression leaves macro ..., which is invalid code.

Most of time, removing a @MainActor or @escaping will cause type-checking failures. The same is true for @expression on macros.

@s-k

I think the proposed spelling is not self-explanatory and would prefer something like macro(expression)

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.

@s-k

I was surprised that so few of the built-in expression macros can be implemented using ExpressionMacro. It feels like this proposal misses the point a little in this regard.

Yes, that's fair. While many of the built-in expression macros can be declared, they can't be implemented unless we allow the expansion context to access more information.

@s-k

I also don't understand the reasoning why source-location information is unavailable to macro definitions.

We're trying to keep macro definitions self-contained so that we can ensure that we understand and minimize their dependencies on other source code in the file/project. This post goes into some detail about the concerns here.

@s-k

Using the example macro repository, I have implemented a simple version of the #printArguments macro proposed by @davedelong in the macro vision thread.

Very nice! If you're up for it, please go ahead and create a pull request to that repository, where we can collect various macro examples.

@s-k

All in all, the proposal gets a +1 from me. While I think the other types of macros will be more useful to me, I think this is a great start.

I agree that the bigger wins will come from other kinds of macros. Expression macros are the first step, and the easiest one because they are the most contained. Once we start generating declarations, issues around compile-time dependencies and incremental builds that we've only touched on with source locations will become a whole lot more interesting.

Doug