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

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

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

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

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.

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

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

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.

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

>> I see.  Well, I still maintain that
>> 
>>   #define MACRO struct xyz {
>> 
>>   MACRO };
>> 
>> is a different category of beast.
>
> 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.
Of course, the thing I want to do completes one standalone and one
non-standalone syntactic entity, so maybe it's in another category
still.
 
> 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.

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

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

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