On 2019-12-17 16:59, Alexander Grund via Boost wrote:
On 17.12.19 14:50, Edward Diener via Boost wrote:
On 12/17/2019 2:39 AM, Alexander Grund via Boost wrote:
So you want to forbid using e.g. PHOENIX_LIMIT for everyone using Boost.Phoenix? What about in 2 releases after that change someone new comes in and uses the new Boost (the first he has ever used) together with some libPhoenix he wrote and (appropriately) uses PHOENIX_LIMIT as the same for his macros? So what is gained?
It is a macro. Macros do not go into libraries. The libPhoenix he wrote has nothing in it regarding the name PHOENIX_LIMIT. If your hypothetical programmer uses PHOENIX_LIMIT in his code he is told via the preprocessor #error that he must use BOOST_PHOENIX_LIMIT instead.
You misunderstood me. If you (currently) include a header from Boost.Phoenix then PHOENIX_LIMIT will be defined (unless I missed an undef somewhere)
So assume the following: - PHOENIX_LIMIT was renamed to BOOST_PHOENIX_LIMIT - An error was added if PHOENIX_LIMIT is defined - A user develops a libPhoenix (unrelated to boost) and uses PHOENIX_LIMIT as per `<libName>_<macro>` naming convention to do something in the headers of his library (e.g. a constant to cap numbers) - A user (the same or another) uses libPhoenix and BoostPhoenix and includes their headers in this order
--> libPhoenix headers rightfully define PHOENIX_LIMIT, Boost headers detect the "old" name and error out. Boom, broken some unrelated library for no (apparent) reason
This is not worse than the status quo. Except that currently the two libraries may interpret the macro differently. I think, given that PHOENIX_LIMIT is currently reserved for Boost.Phoenix, keeping it reserved still for the deprecation period is not a problem (IOW, not more of a problem than we currently have). The important part is that we set the transition to BOOST_PHOENIX_LIMIT in motion, starting with PHOENIX_LIMIT deprecation and warning the users.