SE-0382: Expression Macros

Evolution Proposal Reviews
9

Before using Swift, I used Clojure a lot. The one thing I miss the most is a good macro system. Therefore, I am very excited about this. I think the general approach is great and the proposal looks good.

Here are some thoughts:

  • Having a good and powerful macro system to be able to implement many 'language features' in user code is exactly the right approach in my opinion. It prevents the compiler from getting too complex. A good example is Codable. While it is great to have a standardized way of encoding types that requires little boilerplate, having it baked into the compiler means that any changes need to go through Swift Evolution, which requires a lot of effort. Moving it to an 'officially sanctioned' library (similar to Swift Collections or Swift Algorithms) would mean that it can react better to developer requirements while still being the default coding framework. Furthermore, if the official library does not fit a given problem, developers can modify the library or create their own using macros.

  • 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.

  • 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. I think the proposed spelling is not self-explanatory and would prefer something like macro(expression) ...

  • 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. I would welcome macros having more information available to allow these types of macros to be implementable. I also don't understand the reasoning why source-location information is unavailable to macro definitions.

Using the example macro repository, I have implemented a simple version of the #printArguments macro proposed by @davedelong in the macro vision thread. Aside from the debugging experience (which will hopefully get much attention), the implementation was pretty straightforward. It can be used like this:

func doSomething(_ a: Int, b: Int) {
    #printArguments()
}

doSomething(42, b: 256) // prints 'doSomething(42, b: 256)'
Full implementation 
public struct PrintArgumentsMacro: ExpressionMacro {
    public static func expansion(
        of node: MacroExpansionExprSyntax, in context: inout MacroExpansionContext
    ) -> ExprSyntax {
        var syntax = node.as(Syntax.self)
        while syntax != nil && syntax!.as(FunctionDeclSyntax.self) == nil {
            syntax = syntax!.parent
        }
        
        guard let functionSyntax = syntax!.as(FunctionDeclSyntax.self) else { return "" }
        let signature: FunctionSignatureSyntax = functionSyntax.signature
        let parameterList = signature.input.parameterList
        
        // For a function `doSomething(_ a: Int, b: String, c: Double)`, the expanded epression shall be `print("doSomething(\(a), b: \(b), c: \(c))")`
        
        let parameters = parameterList.map { parameter -> String in
            let potentialLabel = parameter.firstName!.withoutTrivia().description
            let label = potentialLabel == "_" ? nil : potentialLabel
            let potentialName = parameter.secondName?.withoutTrivia().description ?? potentialLabel
            let name = potentialName == "_" ? nil : potentialName
            var string: String
            if let label {
                string = "\(label): "
            } else {
                string = ""
            }
            if let name {
                string += "\\(\(name))"
            } else {
                string += "_"
            }
            return string
        }
        let parametersString = parameters.joined(separator: ", ")
        
        return "print(\"\(raw: functionSyntax.identifier.description)(\(raw: parametersString))\")"
    }
}

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 am excited about the possibilities that macros bring.

And on a personal note, thank you @Douglas_Gregor for the great work you put into property wrappers and macros to put more power into the hands of developers!

6 Likes