On 16.12.19 17:38, Edward Diener via Boost wrote:
On 12/16/2019 10:22 AM, Niall Douglas via Boost wrote:
#if defined(PHOENIX_LIMIT) && !defined(BOOST_PHOENIX_LIMIT) #error In Boost 1.xx PHOENIX_LIMIT was renamed to BOOST_PHOENIX_LIMIT. Please upgrade your code to reflect the new name. #endif
I am with Niall in this as I think that all Boost library macros should begin with BOOST_SOMELIBRARY_UPPERCASENAMEOFMACRO_ETC. Maybe we can, in general, deprecate the current macros that do not follow this pattern and then change them to this pattern in some future Boost release. Needless to say it is really important that C++ macro names are as distinct as possible. We all know how ridiculous it is for compiler implementations to name macros with names such as 'max' and 'min' and all the troubles such names have caused for scores of C++ programmers down through the years.
I do understand Peter though: This is dangerous! Most of the macros have default values, so when changing the name, users won't notice and applications will continue to work. Until they don't. When using the above code snipped (making the old one an error) how long will you keep it? - Very long: You still block the macro you wanted to free - Short: Users skipping versions won't notice the change until it's to late. We jumped from 1.55 to 1.67 not so long ago... Is the condition `if defined(PHOENIX_LIMIT) && !defined(BOOST_PHOENIX_LIMIT)` even justified? What if someone else defines BOOST_PHOENIX_LIMIT and my library/app defines PHOENIX_LIMIT? Now I don't get an error and stuff breaks when I don't expect it. My proposal: Evaluate each macro carefully. Where changing the macro issue a deprecation message (suppressible per macro) for a couple releases (3? 5? 10?) when the old one is defined. Only change macros where not defining it by the user will lead to compile-time errors. E.g. for BOOST_PHOENIX_LIMIT I think this was the maximum number of arguments supported and not defining it bigger will make code using more args fail to compile. This would be OK. For other macros provide a BOOST_ version and error out if both are defined. So users can start using the "good" ones and docs should only mention them (or hide the old names under a "see there") But the old ones must be kept for those. Mistakes were made, can't really change that now. Alex