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

From: David Abrahams (dave_at_[hidden])
Date: 2005-07-16 08:27:02

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

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

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

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

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

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.

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

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

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

No.  I'm sorry to be blunt, but "by proxy" or otherwise, it isn't a
design criterion for me.  Accessibility and comfort for my users is
the criterion.  I don't really care *why* they're more comfortable.

> You've given the argument that "many people think it looks more
> natural", 

Yes.

> which is another way of saying "looking like the
> underlying syntax".  

I'm not sure of that, but I really don't care.

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

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.

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

I didn't say we could make it "that syntactically pleasing."  I'm
saying syntactic pleasantness counts, and we do have the power to make
choices on that basis in the design of macros.

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

Only if you misjudge the motivations of the author.

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