Re: [boost] Call for interest - BOOST_AUTO_FUNCTION

Subject: Re: [boost] Call for interest - BOOST_AUTO_FUNCTION
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2010-10-19 03:34:56

On Tue, Oct 19, 2010 at 1:10 AM, Jeffrey Lee Hellrung, Jr. <
jhellrung_at_[hidden]> wrote:
>
> Whichever keywords you choose is ultimately up to you, but, generally
> speaking, "such-and-such syntax-highlights better in IDEs" doesn't seem like
> a good rationale to base interface and designed decisions of any kind on.
>  I'll leave it at that though.

Just goes to show that you can't please everyone. Keep in mind they weren't
keywords at the start of this thread, it was a suggestion.

The rationale for reusing keywords are that they are one less thing for
users to remember and they highlight if you spell them correctly (macros
like this tend to blow up in your face if you happen to misspell something,
so this is actually a very good thing). "if" and "not" will highlight in C++
IDEs because they are C++ keywords meaning users will know when they get it
right. "unless" does not have that advantage. If highlighting weren't an
issue, I'd likely still be using "requires" rather than "if", but I decided
on "if" because requires isn't a keyword (yet) and therefore doesn't
highlight. When trying to remember which parameter ID to use, it's not much
of a stretch at all to think that users may misremember "requires" as
"require" or "required" or something similar, but their IDE won't be able to
help them out. The same goes for "requires_expression". Such problems don't
exist when the IDs being used are "if" and "try". Since all of the other
Parameter IDs are keywords, I'd rather have "not" over "unless" for
consistency's sake more than anything else.

Anyway, "not" is just there for convenience anyway, kind of like what
disable_if is to enable_if. I'm not even sure it will be there in the end as
it is functionally no different from just wrapping your metafunction in
mpl::not_ or doing !your_metafunction::value.

I'm getting tired and annoyed by this discussion, not to anyone's fault,
it's just getting a bit silly (poop jokes aside). Personally, I don't really
care what the exact names are as long as they make sense and are easy to
remember. Everyone will have their opinion one way or the other and I'm just
going to draw the line here. No more name changes. All of these details can
be worked out after I submit it for review, and at that point, pending it
even gets accepted, if there is a strong opinion in one direction I will
make changes, but as of right now I'd rather just get back to focusing on
functionality.

-- 
-Matt Calabrese