As I'm typing this post, there is a continuing discussion on the Boost developers mailing list about what to do with compile warnings reported in Boost code. There seem to be two opinions on the subject.

In the blue corner, we have people arguing that the compiler is your friend and if it tells you that there might be a problem lurking in your code, you should appreciate that and take whatever action is needed to "fix" the warning.

In the red corner, people argue that warnings don't necessarily indicate problems, that some compilers are plain silly, and that each Boost developer should be free to pick whatever warnings level is appropriate for them.

But before anyone has an opinion on the subject of warnings, we need to be on the same page about

What warnings are (and what they are not)

A common misconception is that compiler warnings indicate problems in the program that are not as severe as errors but should nevertheless be "fixed".

Actually, warnings report facts about the program being compiled for which the C/C++ standard does not require the compiler to issue an error. We can classify them in the following categories:

1. Warnings that indicate definite errors, such as when a printf format specifier doesn't match the type of the variable being passed.
2. Warnings that alert us about possibly unintended semantics, such as tricky operator precedence or implicit type conversions.
3. Warnings that help enforce "good" coding standards, for example messages that report the use of C-style casts.
4. Warnings that push corporate interests, such as the infamous MSVC C4996.

In a corporate environment, such classification helps managers craft a sensible warnings policy that maximizes the output of a particular development team targeting a particular set of platforms.

For a project like Boost, realistically, the classification is much simpler:

1. Warnings that a particular Boost developer finds useful, and
2. Warnings that Boost users find annoying.

Except that by definition 1) is a subset of 2), since many Boost users compile in environments that enable all warnings.

Therefore, we're left with

1. Warnings that users find annoying.

which is another way of saying "any warning issued by any version of any compiler on any platform Boost is compiled on."

Realistically, the only sensible way to achieve this goal is to simply suppress (disable) all warnings in Boost releases, preferably without disabling them for Boost developers:

The only alternative is to require Boost developers to "fix" all warnings on all versions of all compilers on all platforms Boost is compiled on; (obviously?) "fixing" only some warnings that a committee of some sort labeled as "important" still requires disabling all (other) warnings, assuming we are committed to provide warnings-free user experience.

And if that's not our goal, then we should be satisfied with the statu quo: Boost developers address most warnings reported by Boost users.

Formatting hint: when posting comments, surround code blocks in [@ and @].