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

From: David Abrahams (dave_at_[hidden])
Date: 2005-07-15 05:33:35

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

>> -----Original Message-----
>> From: boost-bounces_at_[hidden] 
>> [mailto:boost-bounces_at_[hidden]] On Behalf Of David Abrahams
>
>> > It's more convenient in exactly one way only: a particular *editor* 
>> > has trouble properly automatically formatting code.
>> 
>> 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.

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

It sounds like you're saying:

  - Some naive users think macros are the same as functions

  - That causes them to make mistakes

  - Thererefore we should design all macros to forbid a trailing
    semicolon in order to discourage that misconception

  - And the following are non factors

    - That the rest of users have no illusions about the role of
      macros

    - How much easier it makes things when the macro requires the
      semicolon

    - That requiring the semicolon can keep a category of errors from
      creeping into code

In other words, everything else in service of wiping out some people's
silly misconceptions about what macros are.  Have I got that right?

For my part, I think my priorities are exactly inverted from yours.

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

>> > macro only accomplishes *part* of its function--it only generates 
>> > *part* of the code.
>> 
>> Sorry, _what_ means the macro only accomplishes *part* of its 
>> function?
>
> When a macro can be designed to encapsulate a standalone syntactic entity but
> doesn't.  E.g.
>
> #define MACRO struct xyz { }
>
> MACRO;
>
> ...is no different from...
>
> #define MACRO struct xyz {
>
> MACRO };

Well, of course it's different.

> It starts it, but it doesn't finish it.  

Ahem.  From the C++ standard grammar summary:

  class-specifier:
     class-head { member-specification(opt) }

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

It sure is.

>> > Sometimes that's necessary; this isn't one of those cases.  The 
>> > viewpoint that must prevail is that macros are code writers.
>> 
>> 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.  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.

> and adding or elliding the semicolon doesn't make it easier or
> harder to use.  

I am only becoming more convinced to the contrary.

> It just makes it look more like a function call--to some editors as
> well as users.  

It doesn't "just" do that.

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