-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] 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