-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andy Little
I wouldn't mind this approach. In fact, I kind of like it. It puts the appropriate emphasis on a macro's syntactic effect. But I don't think that it will help the various problems that people have (like extra semicolons) or editor issues. For example, if a macro expands to a function definition, then there shouldn't be a semicolon, which puts us squarely back in the situation we have now.
Not sure I understand this. The two macros should be classed separately, consulting the grammar for the correct useage.
The problem is that users wouldn't be able to put a semicolon after this... #define MACRO() void f() { } MACRO(); // error ...which is the same situation, regardless of what MACRO expands to, that we have now. Some people think that its more natural to put the semicolon, and some have editor problems without the semicolon.
I'm guessing that David Abrahams macro expands to a simple-declaration in the grammar( if the semi-colon is included, else it would be incomplete grammatically), therefore it should include the semicolon, which is the only mandatory part incidentally. However the macro as function-definition is grammatically complete without it. Of course with this approach macros would ideaaly be complete grammar entities, which is much neater than trailing semicolons IMO.
Even without the semicolon, you can still match a structure declaration (without a semicolon) to a grammar production. It just isn't a more-or-less standalone grammar production. I do like this approach, though. It gives a rigorous syntactic meaning where there isn't one inherently. One thing that concerns me, however, is that not all macro expansions match a single grammar production (e.g. a class definition with an out-of-line member function definition after it), and defining a macro in terms of a lower-level grammar production implies that it can be used like that grammar production. For example, #define MAKE(id) struct id { } MAKE(abc) xyz; In most cases, I don't think that allowing this is the intention (though sometimes it is), so I think you'd have to stipulate that the matched grammar production is as high-level as possible yet still achieve the basic intent. Regards, Paul Mensonides