"Paul Mensonides" <pmenso57@comcast.net> 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