Re: What to do about Boost libraries which use user-defined macros which are not BOOST_ prefixed

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2019-12-17 14:13:40

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.