SE-0382 "Expression Macros" mini-pitch for updates

[Douglas_Gregor]

Hi all,

The review of SE-0382 as well as work on additional kinds of macros has uncovered some things we'd like to tweak in the proposal. I've put up a pull request with the set of changes we'd like to make, itemized here:

• Switch @expression to @freestanding(expression) to align with the other macros proposals and vision document.
• Make the ExpressionMacro.expansion(of:in:) requirement async.
• Allow macro declarations to have opaque result types, and define the uniqueness rules.
• Simplify the grammar of macro declarations to be more function-like: they always require a parameter list, and if they have a return value, its type is specified following ->. To account for macros that take no arguments, omitting both an argument list and trailing closures from a macro expansion expression will implicitly add ().
• Make MacroExpansionContext a class-bound protocol, because the state involving diagnostics and unique names needs to be shared, and the implementations could vary significantly between (e.g.) the compiler and a test harness.
• Introduce a general location operation on MacroExpansionContext to get the source location of any syntax node from a macro input. Remove the moduleName and fileName, which were always too limited to be useful.
• Allow macro parameters to have default arguments, with restrictions on what can occur within a default argument.
• Rename createUniqueLocalName to createUniqueName; the names might not always be local in scope. Also add a parameter to it so developers can provide a partial name that will show up in the unique name.

[EDIT: Many expression macros need location information, so I've pulled a location operation into the MacroExpansionContext that provides access to this information]

Doug

[s-k (Stephen Kockentiedt)]

The changes look good. Thanks for continually pushing the proposal forward! The location operation looks very useful, although I have not yet tried to work with it.

One weak spot I still see is the lack of type information, especially now that the parent of the main syntax node is always nil, making it impossible to look 'outside' the macro invocation itself.

[Douglas_Gregor]

@s-k

The changes look good. Thanks for continually pushing the proposal forward! The location operation looks very useful, although I have not yet tried to work with it.

The implementation of location hasn't made it in a snapshot yet, but should be there once we release a February 3rd snapshot.

@s-k

One weak spot I still see is the lack of type information, especially now that the parent of the main syntax node is always nil, making it impossible to look 'outside' the macro invocation itself.

Yes, this is a weak spot. The design here is complicated enough that I'd rather treat it as a separate discussion, because I feel like we're going to be inventing a type system representation along the way.

Doug