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

From: David Abrahams (dave_at_[hidden])
Date: 2005-07-15 09:14:46

"Paul Mensonides" <pmenso57_at_[hidden]> writes:

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

It is different in that many compilers won't detect it.

> The intentionally strong language is about people that habitually
> expect that semicolons after macro invocations at namespace scope
> are supposed to be there.

Well, some part of my brain obviously expects that habitually.

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

I'm just trying to say that modifying the code is much easier for some
people than for others.  If you're the author, it's usually trivial,
but all sorts of restrictions get in the way for other people, to
varying degrees.

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

I see where you're coming from.

>>   - That causes them to make mistakes
>
> Indeed, except with what I said.

Huh?

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

Okay, that's a more refined point-of-view.

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

I understand you to have two objections to that point of view, which
can be summarized as

  - It leads some people to think that max(a,b) is a function call
  - it is self-perpetuating.  

I understand the first objection, but to buy into the 2nd one I have
to accept that it's an invalid goal before I can believe the reasons
you give for it being invalid.  So far that looks like a leap of
faith.

> It causes errors far more insidious that extra semicolons.

What sort of insidious errors do you think I make because of that
point of view?

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

and 3) many people find it "more natural."  We have had reports in
this thread that the semicolon sometimes comes up automatically, and
not seeing the semicolon causes people some "cognitive dissonance."

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

Somehow I have trouble seeing a tiny design choice like this one as
the cause of those problems.

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

Somehow, I do have that expectation though.

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

I'm asking for clarification based on my understanding of what you've
repeatedly said.  If I haven't got it right, just tell me so.

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

Now _that_ would be heavy-handed :)

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

Wow.  I don't know what to say.

I don't know about the priorities of the rest of Boost, but I guess
purity is a lower priority for me than some other things.

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

Sorry, I don't understand yet.

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

I see.  Well, I still maintain that

  #define MACRO struct xyz {

  MACRO };

is a different category of beast.

>> > As I mention below, sometimes it isn't possible, but this isn't
>> > one of those cases.
>> 
>> It sure is.
>
> No, it isn't.  

Now that I understand what you meant by "standalone", I agree that it isn't.

>> >> That is my viewpoint, for sure.  aI'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.

Agreed.

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

Yeah, so far that's how the balance tilts for me.  I understand your
point of view better now, but still am not persuaded to raise my
estimation of the importance of that principle.

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

Don't underestimate how much easier it gets for people to read and
write code when it's syntactically pleasing.

>> the semicolon makes it easier and less error-prone even for 
>> people with a correct viewpoint on the role of macros.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com