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

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2019-12-16 16:58:12

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