{"id":37365,"date":"2022-10-17T16:22:05","date_gmt":"2022-10-17T20:22:05","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=37365"},"modified":"2022-10-17T16:23:51","modified_gmt":"2022-10-17T20:23:51","slug":"a-possible-vision-for-macros-in-swift","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2022\/10\/17\/a-possible-vision-for-macros-in-swift\/","title":{"rendered":"A Possible Vision for Macros in Swift"},"content":{"rendered":"

Douglas Gregor<\/a> (via Joe Groff<\/a>):<\/p>\n

Macros can offer a way out of this conundrum, because they allow one to introduce boilerplate-reducing facilities without requiring a bespoke language extension or a separate source-manipulating tool to do so. A good macro system could replace the need for a swath of new language features, but one must be careful not to degrade the development experience by making it too hard to build good tools (i.e., C macros are notorious for breaking tooling).<\/p>\n

We propose to introduce a macro system into Swift. At a very high level, macros can be explicitly triggered with syntax such as #stringify(x + y)<\/code>, subsuming a number of existing expressions that use similar syntax already (#line<\/code>, #colorLiteral(...)<\/code>, etc.) with a general features. Macros can also be triggered more implicitly in response to type checking, e.g., applying a macro to the argument passed to a function. Macro arguments are type-checked so that tooling behaves similarly to today, but macro evaluation involves transforming the syntax so that it can serve a number of different use cases.<\/p>\n

A possible vision for macros in Swift<\/a> talks about the design space and proposes a path for macros in Swift.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n