On Tue, Oct 19, 2010 at 1:10 AM, Jeffrey Lee Hellrung, Jr. < jhellrung@ucla.edu> 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