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

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-07-15 04:28:18

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

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

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

It starts it, but it doesn't finish it.  As I mention below, sometimes it isn't
possible, but this isn't one of those cases.

> > 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,
and adding or elliding the semicolon doesn't make it easier or harder to use.
It just makes it look more like a function call--to some editors as well as
users.  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.

Regards,
Paul Mensonides