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

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-07-16 04:21:47

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

> >> Now _that_ would be heavy-handed :)
> >
> > Yet we have some of those policies already.  One example is tabs in 
> > source files.  It is a total non-issue except in one situation:
> > using tabs in the middle of a line of code rather than to indent it.
> 
> Actually, no.  IIRC it's a GNU convention to use 8-space tabs 
> and indent in multiples of 4 spaces, so lines start with a 
> sequence of zero or more tabs and successive levels of 
> indentation end either with a tab or with 4 spaces.  When I 
> change my tab width to anything other than 8-space tabs, 
> nothing looks right.  If I change to 3-space tabs I can even 
> get the indentation to invert.  Now, you can tell me "I meant 
> to rule that case out too," but it just goes to show that 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).

> I really don't want to get into an argument about whether the 
> Boost tab policy is wrong or right...  like many other things 
> I've been discussing today, the Boost policy (ca. 1998) is in 
> place for practical reasons.  If someone could find a simple 
> and proven policy that allows tabs at the beginning of a line 
> and is easy for everyone to follow without silly 
> misinterpretations, I'd be fine with it.  We didn't have time 
> -- or maybe enough smarts -- or maybe enough people who cared 
> enough about being able to use tabs -- back then, to figure 
> out how to be maximally permissive without causing problems.  
> 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.  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.

> > My conception of Boost, and the basis for my involvement 
> (for whatever 
> > its worth), is that Boost isn't just about providing tools 
> to get the 
> > job done.  It's about providing tools--written the right 
> way--to get 
> > the job done the right way to the greatest extent possible 
> given the 
> > compilers and platforms that we have to deal with.
> 
> 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; 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.

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

> FWIW, one of the main reasons I brought this issue up was 
> that I was hoping you'd convince me that the reasons to do it 
> your way were important enough to outweigh the reasons to go 
> the other way.

I know.

> > It is certainly in terms of the convenience and usability of the 
> > author, but in terms of the complexity required for a use of a 
> > construct to be understood by the author and the terseness or 
> > verbosity of the expression of that construct by the 
> author.  Having 
> > no semicolon doesn't make it significantly less convenient 
> nor does it 
> > increase complexity.  Rather, it merely requires a programmer's 
> > perspective to be a little different--but not in a way that is 
> > difficult to grasp.
> 
> Trivial things do add up.

They can add up.  Sometimes they are trivial enough that they approach zero
overhead in comparison with the alternative.  I think that this is one of those
cases.  The concepts aren't difficult to understand.

> > Not from my perspective.  In both cases, a standalone entity is 
> > started, but not finished--for no good reason.
> 
> That last part is debatable, but aside from that what you say is true.
> OTOH, the case above does not complete any syntactic entity 
> at all, whereas the struct declaration without the trailing 
> semicolon does.

I'm referring to a syntactic entity that doesn't require addition syntax to be
valid C++.  Obviously, take that with a grain of salt.  I don't mean that macros
should provide the surrounding function if they produce an expression statement.

> > The only difference is that MACRO }; is obviously different 
> from any 
> > normal C++ syntactic construct.
> >
> > If I *had* to choose between intentionally designing macros to not 
> > look like underlying syntactic constructs and intentionally 
> designing 
> > macros to look like underlying syntactic constructs, I'd choose the 
> > former, but both a flawed constraints.  Doing either, IMO, is bad 
> > design.
> 
> Well, I don't view myself as doing either one, FWIW.  
> "Looking like underlying syntax" is not a design criterion for me.

It appears to me that it is (a design criterion for you) by proxy.  You've given
the argument that "many people think it looks more natural", which is another
way of saying "looking like the underlying syntax".  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 { };

#define MACRO_II(id) MACRO(id) using namespace ::empty

// client with editor problems code...

MACRO_II(xyz);

> >> Don't underestimate how much easier it gets for people to read and 
> >> write code when it's syntactically pleasing.
> >
> > If the preprocessor had more of an ability to manipulate 
> syntax or was 
> > part of the syntax (as in Lisp or Scheme), then we could do this.
> 
> Do what?  Are you saying we can't syntactic pleasantness into 
> account because the PP can't manipulate syntax?

I'm saying that we can't make PP syntax as syntactically pleasing as the
underlying language syntax (e.g. a healthy distribution of operators, keywords,
etc.).  If we could manipulate the syntax, then we could make it that
syntactically pleasing.

> > But it doesn't, and all this does is make it look like the macro is 
> > something that it is not.
> 
> Still looks like a code-generating macro to me, with or 
> without the semicolon.

I agree, but I also think it looks like a macro that's supposed to act as a
syntactic entity.

Regards,
Paul Mensonides