Macro and header names are too plain and conflict easily about better-enums HOT 4 CLOSED

The first change seems reasonable to do now. It would be nice to get the opinions of more users first, but I am not sure how to solicit them.

I'll probably hold off on the second. Users are still free to put enum.h in a subdirectory of their choosing, as you mentioned. I may nest enum.h in a better-enums subdirectory later, if the header gets split into multiple files, or if there are a lot of "extras" to distribute. I do already have such a better-enums directory – it's just not first-class, since the only thing there is the C++17 demo.

from better-enums.

The file nesting isn't that important, it was a side-suggestion. Let's drop that off the plate for now to keep the discussion more focused.

Concerning the macro name, I'd argue that doesn't require feedback at all. Simple macro names are notorious for conflicting with symbols. It's a non-decision to rename it. I think if you expect your library to be used in professional, production code which has millions of lines of code and numerous incoming dependencies, the rename will be an absolute requirement.

Again, I'd like to refer you to the Boost.Preprocessor library. You'll notice they prefix all macros with BOOST_PP. This is akin to a namespace in the macro world, as you know. The verbosity and "extra characters to type" tradeoff is well worth the guarantee that your library will work out-of-the-box in most (if not all) code bases regardless of size and number of dependencies.

from better-enums.

As I said, I am in favor of changing the macro name. I merely added that it would be nice to get additional feedback, since a large number of people seem to have been fine with ENUM, and also for good ideas for a replacement name that only 2 people (us) might not come up with. However, I won't be waiting for feedback, since I don't have an efficient way of getting it at this point. I will do this change together with the other changes we are currently discussing.

from better-enums.

I like the name ENUM too, honestly if there was no conflict the name is perfect. But scattering the #undef's all over our code base would quickly land me lots of ugly looks from my coworkers in my code reviews :-)

Thanks for welcoming my feedback, you've done a great job.

from better-enums.