Re: [boost] Macros at namespace scope: trailing semicolon?

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-07-15 07:13:38

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] 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.

Thanks for clarifying.

> > 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
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.