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

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-07-16 17:22:30

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of David Abrahams

> >> it is a nontrivial thing to create a policy that actually works.
> >
> > In this case it is trivial.  Use tabs xor spaces to indent 
> (and only 
> > to indent).
> 
> So, no spaces anywhere else on the line?  Try again.

It doesn't address non-indentation whitespace, and even if it did, it would
still be trivial.

> >> We wanted to get about the business of building Boost, and that 
> >> policy is what we ended up with.
> >
> > I don't want to get into this argument either.  I mention 
> it because I 
> > think it is a heavy-handed policy.  It is a ban on 
> something that can 
> > cause problems, but doesn't have to cause problems.
> 
> Sorta like the design choice we're debating right now?

It is nothing like what we're debating.  Adding a semicolon after a macro
invocation is conceptually broken.

> > For my part, it doesn't matter much because I write 
> preprocessor code 
> > differently than regular code.  I always use spaces to indent 
> > preprocessor code, but never in my other work.  Otherwise it makes 
> > writing code require an editor capable of treating 
> sequences of some 
> > number of spaces as tabular indentation.
> 
> Your editor can't do that?

Not all of my editors can do that.  There are times that I'll open something as
simple as notepad to edit something because it is faster.

> >> Right.  But, people of goodwill and reasonable intelligence can 
> >> disagree about how to evaluate "the right way."  It's not an 
> >> absolute.
> >
> > Actually, the right way nearly always *is* an absolute;
> 
> I said that *how to evaluate* "the right way" isn't absolute. 
>  I believe that, and as a result people can come to different 
> conclusions.

Okay.

> > it's just
> > that none of us are smart enough to always know what that right way 
> > is.  I generally don't even bother taking sides unless I've given a 
> > subject a great deal of thought--even if I have an opinion. 
>  This is 
> > one case that I've been thinking about for years.  
> Specifically, the 
> > root causes of the antipathy for the preprocessor.
> 
> Yes, and that is a more important issue to you than to some 
> other people.  A person's system of values will affect how he 
> evaluates "the right way."

Indeed.

> >> > If that isn't part of it, I have no interest in sticking around.
> >> > Catering to editors in the face of purity is taking 
> "compilers and 
> >> > platforms that we have to deal with" to the point of 
> being asinine.
> >> 
> >> Are you being intentionally insulting?
> >
> > No, I'm saying what I think.  I honestly think it is ridiculous for 
> > Boost to worry about editor compatibility.  We have enough 
> difficulty 
> > with just compiler compatibility.
> 
> It's not the same class of problem at all.  For one thing, 
> it's much less critical: when a compiler is incompatible with 
> some code, the code simply doesn't work.  There's not much to 
> worry about if you've found a way to do it that's compatible 
> with all known editors and causes problems for none.

Except that it is a workaround for an editor, but there is nothing in the source
code that indicates that it is a workaround at all.  It is an unnecessary design
alteration, and the design is not as conceptually well-founded as the original.

> > If an editor has problems with a construct, then a 
> workaround should 
> > be applied for that editor (or family of editors), but not globally.
> > You can take your macro (which, for the sake of argument, 
> includes the 
> > semicolon) and wrap it in another macro:
> >
> > // library code:
> >
> > #define MACRO(id) struct id { };
> >
> > // normal client code:
> >
> > MACRO(xyz)
> >
> > // client with editor problems library code...
> >
> > namespace empty { };

Except without this   ^^^ semicolon, of course.

> > #define MACRO_II(id) MACRO(id) using namespace ::empty
> >
> > // client with editor problems code...
> >
> > MACRO_II(xyz);
> 
> I'm really surprised you'd suggest that.  The impurity of 
> that workaround is enormous compared with that of the 
> workaround that adds a semicolon when the macro starts without on.

Except that the impurity wouldn't be in Boost, and even if it was, it would
clearly be a workaround instead of an alternate design.

> > I agree, but I also think it looks like a macro that's 
> supposed to act 
> > as a syntactic entity.
> 
> Only if you misjudge the motivations of the author.

Not really.  My judgement is clear.  It is either a workaround for an editor (or
editors), a way to please users by making it look like a regular statement, or
both.  Despite what you say, frankly or otherwise, the last is the motivation.
It's a transitive situation.  If your motivation is to do what users want, but
their motivation is X, then the motivation for a design is X.  You aren't
buffered by the indirection.

Regards,
Paul Mensonides