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

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-07-17 22:35:43

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

> If I make knives and my motivation is to make knives that 
> please my customers, and some customer likes a particular 
> design feature because it makes the knife an effective murder 
> weapon, that doesn't mean that the feature is motivated by murder.

If you want to please your customers, *knowing* what their motivations are, then
the motivations are transitive.  You're right--if a particular customer likes it
for bad reasons, and that user is representative of only a tiny minority, then
that's one thing, but if it is one of the predominant motivations, then it's
another, and then you *are* responsible though possibly not as responsible to
the same degree.  To continue with analogies...  If your neighbor comes over and
asks to borrow a knife but doesn't reveal his intentions and then kills his wife
with it, you're not at fault, but if he comes over and asks to borrow a knife so
he can kill his wife, and you give it to him, then you are *at minimum*
partially at fault.  In the United States, at least, it'd be called an
"accessory to murder".

Despite my disagreement regarding the editor issue, that motivation is
significantly less damaging than the "looks more natural" motivation.  I
wouldn't be so utterly turned off (putting it lightly) by the workaround, if it
weren't for the other getting such a high degree of credence.  Beyond that,
there is nothing in the source to indicate that it *is* a workaround, leading to
users thinking that the technique of making it look more inline with the
underlying syntax is condoned by Boost--an entity with some authority on good
coding practice, regardless of Boost's actual intent.  This is a motivation
known to be [at least one of] the predominant motivations in the user base based
on the sampling that we've had here (and elsewhere)--which is very likely to be
a good generalization across the rest of the user base.  From a workaround
point-of-view only, which is the only thing that is even in the ballpark of a
good perspective, IMO, it's a question of whether a design workaround should be
explicit--I think it should be.  It isn't hard to provide a separate workaround,
either in Boost or locally by users of these editors (that are purportedly
smart, but aren't smart enough to handle a language with dynamic syntax).  It
doesn't even have to be on a per macro basis.  It could be:

MACRO(xyz) SEMICOLON;

I agree that that is ugly, but in light of it being an explicit workaround and
in light of the fact that users can define a macro to make it look better if
they wish (just maybe while doing so they wonder why Boost didn't do it), it is
worth the less-than-ideal syntax.

Regards,
Paul Mensonides