Rob Stewart <stewart@sig.com> writes:
Having said all of that, I find the following compelling:
From: "Peter Dimov" <pdimov@mmltd.net>
If you let people add a semicolon after the macro, how can you change the macro later in a way that doesn't tolerate a trailing semicolon? The expansion of the macro is an implementation detail; the interface shouldn't depend on a particular expansion.
I have, in fact, seen situations where this arose. One has to visit many files to remove trailing semicolons if one uses a compiler that complains about the extras.
On that basis, I am convinced that semicolons should be kept within the macro. Indeed, I plan to follow that approach in my own code henceforth, despite the formatting trouble it will cause.
It doesn't seem untenable to suggest having editor indentation logic special-case a commented-out semicolon to be treated as a real semicolon. The code colorizer could even color the comment the same way as it colors a real semicolon, too. statement(); MACRO() //; statement2(); Hmm. -- Chris