-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams
No, I pointed out several other practical considerations, not least of which is that if you make a mistake with the other convention, your compiler is unlikely to tell you about it and your code will be nonportable.
Such a mistake is the result of a fundamentally flawed viewpoint.
Wow, that's pretty strong language. I've made the mistake, and I just don't see how my viewpoint is "fundamentally flawed." I don't pretend macro invocations are function calls. I always view them as code generators. I'm just not always sure which code they're generating, and -- yes -- sometimes I write fast and the keystrokes `) ; Ret' just flow off my fingers without my brain having a chance to intervene.
...which is no different than any other syntactic error that one might make when typing, and is usually the easiest kind of error to fix. The intentionally strong language is about people that habitually expect that semicolons after macro invocations at namespace scope are supposed to be there.
One which I don't think we should accommodate. Worst case scenario is that someone makes the mistake and it has to be trivially fixed in a port. Fixing a "semicolon not allowed here" error is hardly difficult.
It depends whether you're the person at liberty to change the code.
...and you can't get those that are to fix it--which means that you're attempting to use source code on a compiler that it hasn't been tested on without the ability to modify it at all.
It sounds like you're saying:
- Some naive users think macros are the same as functions
I'm saying that *most* users, naive or otherwise, view (for example) a 'max' macro as returning the greater of two (or more, I suppose) arguments.
- That causes them to make mistakes
Indeed, except with what I said.
- Thererefore we should design all macros to forbid a trailing semicolon in order to discourage that misconception
No, we should design macros without this being relevant. Generally speaking, we should define them to be self-contained entities that produce self-contained syntactic constructs.
- And the following are non factors
- That the rest of users have no illusions about the role of macros
I'm not referring to someone that is so naive that he doesn't know the difference between a macro and a function. I'm referring to typical C++ programmers, including just about everyone involved in this conversion, that thinks that making macros look like underlying language syntax is a valid goal. It causes errors far more insidious that extra semicolons.
- How much easier it makes things when the macro requires the semicolon
How much easier does it make things? I'll that I've seen here is 1) editors don't indent properly because they can't handle it, and 2) extra semicolons aren't caught by some compilers making the code non-portable. I'm not saying these are absolute non-factors, I'm saying that neither is a strong enough argument to violate (what should be) the principle and therefore propogate the same problems that we've had with the preprocessor for years and years.
- That requiring the semicolon can keep a category of errors from creeping into code
Except that it isn't preventing some kind of insidious error. Instead, its a trivial error that is trivially fixed. I don't think that you can reasonably expect to use some source code with a compiler that it hasn't been tested on without having to change it at all. Extra semicolons are the least of your worries then.
In other words, everything else in service of wiping out some people's silly misconceptions about what macros are. Have I got that right?
I think you need to reread what I've repeatedly said, Dave, instead of make assertions based on what you infer. Your own positions are rarely less than heavy-handed. This isn't a piddly little case of some silly misconceptions. It is a pervasive viewpoint that is flawed, which leads to errors, and which leads to broad denouncement of the preprocessor. It is an erroneous perspective, not a misunderstanding of the differences between macros and functions.
For my part, I think my priorities are exactly inverted from yours.
Then make another Boost policy. My priorities revolve around making things as pure as possible given the environments that we have to deal with. If that is divergent with Boost's priorities, then consider it the end of my affiliation with Boost.
The last thing we should be at all concerned about is automatic formatting in some editor.
Convenience, usability, and the chance of not making a trivial unintentional error are important factors in the design of any component.
Convenience and usability from the point of view of other source code, not how that source code is written.
I _thought_ for a minute I understood what you meant by "from the point of view of other source code," but now I'm less sure. Seems to me "other source code" doesn't care about convenience and usability; only its author does.
From the point of view of other source code in terms of the source code complexity and size of a use of a construct.
It starts it, but it doesn't finish it.
Ahem. From the C++ standard grammar summary:
class-specifier: class-head { member-specification(opt) }
...which is why I said "standalone". The above cannot stand alone in any meaningful way. It *has* to have more following it or it does not form a valid syntactic construct.
As I mention below, sometimes it isn't possible, but this isn't one of those cases.
It sure is.
No, it isn't. Of course the macro can include any necessary trailing semicolon. This isn't one of those cases that where a macro cannot fully (and reasonably) encapsulate the entire syntax.
That is my viewpoint, for sure. I'm also in favor of making them as easy to use and as foolproof as possible.
Making them foolproof can't be done without a perspective shift from the user,
No, that does an end run around the goal: at that point the user is no longer a fool.
No, it doesn't. I'm saying that macros cannot be designed to generally protect against misuse without users' viewpoints being different than what they typically are.
Disabusing people of foolishness is very, very hard, so when providing a library I adopt a "policy of engagement:" I try to design the library based on sound principles, but in such a way that the user can experience success before shedding his foolishness. I hope that one day the sound principles will rub off and begin to enlighten.
Except that in this case (the expression of a library feature), you're severly underestimating a sound principle by letting it be outweighed by the possibility of extra semicolons (which is quite possibly the easiest bug to fix of all time) and by automatic formatting of some editors that many people use (but many people don't).
and adding or elliding the semicolon doesn't make it easier or harder to use.
I am only becoming more convinced to the contrary.
The problem that I have is not so much with catering to editors (though I am against that in principle), but with catering to an incorrect viewpoint. The harm in doing so far outweighs extraneous issues like source code formatting over time.
If that was my motivation, I'd agree. But in fact requiring ^^^^^^^ This isn't a fact; it's your opinion. Most people that want to be able to add
Thanks for clarifying. the semicolon (AFAICT) just think it's more syntactically pleasing.
the semicolon makes it easier and less error-prone even for people with a correct viewpoint on the role of macros.