Hi all,
The review for SE-0415: Function Body Macros ran from December 6rd to December 20th. The Language Steering Group has decided to return the proposal for revision.
Feedback on this proposal mostly centered around concerns that the two forms of macros specifically proposed would not be sufficient to express the kinds of transformations that users want to perform on their code.
Limitations of preamble and body macros
One of the most commonly cited use cases for function body macros was to wrap an existing function body in some other context; for example, to perform tracing or logging. While the proposed design for preamble macros makes it possible to inject both prologue and epilogue code using defer, the inability to examine a thrown error or the function's return value were cited as difficult limitations. As a concrete example, using preamble macros to implement task-local bindings would require the introduction of unsafe APIs in their public interface; the Language Steering Group would prefer if libraries did not have to introduce such unsafe constructs simply to work within macro limitations.
While body macros do not have the limitations mentioned above, the restriction that only one can be applied to a function was seen by many reviewers as diminishing their usefulness, especially in the face of the limitations of preamble macros.
Therefore, the Language Steering Group is requesting that the solution space for something more akin to a "wrapper" macro be explored further to address the issues above.
Lack of closure support
Some other reviewers expressed concerns that the lack of support for function body macros to be applied to closures would be confusing. While the Language Steering Group does agree that it would be useful to have this capability, applying function body macros to closures presents a number of unique challenges that do not apply to regular function declarations. For this reason, we are comfortable slicing closures off as a future direction for their own proposal.
Once the revisions above have been made, the Language Steering Group will schedule another review of the revised proposal.
Thank you for participating in Swift Evolution!
—Tony Allevato
Review manager