I know that I have brought this up a number of times in these forums, so I hope I’m not becoming annoying, but I can’t help but feel that this falls well short of addressing the real problem of lacking proper pattern matching for writing macros anywhere in Base or stdlib. (And I am assuming that this suggestion is more about pattern matching blocks than it is about omitting a begin.)
I realize that there are many suggestions on these forums about adding things to Base or the stdlib which are unwarranted because the suggested functionality is better off in a separate package, but I can’t help but feel that tools for writing easily understandable macro code are a special case, and the existence of this post indicates that others feel the same.
In multiple cases I have found myself in a position of making contributions to packages which contain baffling macro code that is extremely difficult to maintain. It’s not because the authors were bad at writing macro code, it’s rather because with Julia’s complicated AST metaprogramming is simply extremely ugly without special tools, and the authors were either unaware of MacroTools or were nervous about its maintenance (I was explicitly told this by the package authors in at least one case).
I personally would be perfectly happy to continue using MacroTools itself for my own projects, but it seems likely to me that much of the communtiy will remain either unaware of it, or will continue to be unwilling to use it, or perhaps feel motivated to create unnecessary forks. I feel that the proliferation of bewildering, difficult to maintain macro code is very bad for the Julia ecosystem, and I would love if something could be done to “stem the tide” before such code becomes even more prevalant. As you can see from the MacroTools package, pattern matching for metaprogramming doesn’t have to consist of much code itself, but it can save thousands and thousands of lines of confusing, macro code that contributers are afraid to touch.
