Suggestion: type inference

[shaps80]

Hi, when macros were first available I had the same idea as you.

Its great to have type-safety but also to simply remove the runtime cost of parsing the string.

One suggestion (perhaps improvement) I made in my own version was I didn't want to have multiple #color, #uicolor, #nscolor (I also had a couple others for windows, linux support).

If you use the lexical context in your macros you can workout what type the user is trying to convert to:

let color: UIColor = #color("fff")

// macro -- UIColor
context.lexicalContext.compactMap { $0.as(PatternBindingSyntax.self) }.first?.typeAnnotation?.type

And since I'm 95% of the time working in SwiftUI these days, I just make that the default so in those cases no type-annotation is required.

This approach btw, also allows you to detect when the user is defining an extension. So you can even make "theme" definitions nicer. This occurred to me after I saw @Entry and similar macros in recent SwiftUI releases. I checked and enough context is available from a @freestanding(expression) 👍

extension UIColor {
    static let error = #color("0ff")
}

// macro: extension on UIColor
context.lexicalContext.compactMap { $0.as(ExtensionDeclSyntax.self) }.first?.extendedType

You can even mix these, just use the typeAnnotation as an "override" if its defined inside an extension.

Just an idea. Nice work tho 👏

[zijievv]

That's a very interesting idea! However, after some consideration, I've come up with several cases where the type cannot be inferred from the context (MacroExpansionContext).

1. Typealias

   typealias NextStepColor = NSColor
   extension NextStepColor {
   	static var primary: Self {
       #color(hex: "000")
     }
   }

   From lexical context, all we can know is that `primary` is a `NextStepColor`:

   ▿ 2 elements
     - 0 : PatternBindingSyntax
   ├─pattern: IdentifierPatternSyntax
   │ ╰─identifier: identifier("primary")
   ╰─typeAnnotation: TypeAnnotationSyntax
     ├─colon: colon
     ╰─type: IdentifierTypeSyntax
       ╰─name: keyword(SwiftSyntax.Keyword.Self)
     - 1 : ExtensionDeclSyntax
   ├─attributes: AttributeListSyntax
   ├─modifiers: DeclModifierListSyntax
   ├─extensionKeyword: keyword(SwiftSyntax.Keyword.extension)
   ├─extendedType: IdentifierTypeSyntax
   │ ╰─name: identifier("NextStepColor")
   ╰─memberBlock: MemberBlockSyntax
     ├─leftBrace: leftBrace
     ├─members: MemberBlockItemListSyntax
     ╰─rightBrace: rightBrace
   

2. Assignment

   func bar() {
     let color: Color
     color = #color(hex: "000")
     // ...
   }

   From the lexical context, we cannot know what type `color` is.

   ▿ 1 element
     - 0 : FunctionDeclSyntax
   ├─attributes: AttributeListSyntax
   ├─modifiers: DeclModifierListSyntax
   ├─funcKeyword: keyword(SwiftSyntax.Keyword.func)
   ├─name: identifier("bar")
   ╰─signature: FunctionSignatureSyntax
     ╰─parameterClause: FunctionParameterClauseSyntax
       ├─leftParen: leftParen
       ├─parameters: FunctionParameterListSyntax
       ╰─rightParen: rightParen
   

My examples may not represent the most common use cases, but I believe a freestanding expression macro should be freely usable wherever a developer needs it to express a value. If there's even a single scenario where the macro can't analyze the context to perform its task, it could leave the user confused and wondering why the macro failed to expand.

This is what I've considered so far. I haven't done a deep dive to find a possible solution. Glad to hear your thoughts!

[shaps80]

That’s great feedback and absolutely valid. I guess from my pov I’d rather handle the really common scenarios really well even if the less common cases require some decent error reporting (diagnostics).

Versus not being as intuitive as possible all of the time, allowing edge cases to introduce unnecessary constraints.

Just my two cents. I see your points tbf and they are completely valid, the type alias example is an interesting one because I should’ve seen that in some of my own cross platform code where I often use a type alias however i guess I largely used SwiftUI Color (my fallback) and didn’t see any issues in my particular case but that’s not a good rep of the larger community.

Maybe my final sell would be, no one HAS to use it. It’s an additional convention APi. We do that that all the time in engineering. Introduce convenient (but often less flexible) API and mostly it improves the developer experience. But sometimes we just have to use the more verbose/involved (flexible) API. You alrsdy have that.

Just a thought 🤷🏼‍♂️