I’m pretty new to boost, but I’m sensing a desire to have cake and eat it too … correct me if I’m wrong of course!
I see several places in the bug tracking system where people complain about compiler warnings and are told that fixing that sort of thing is completely ridiculous and the bugs are closed as “won't fix”.
But then warnings-as-errors is enabled in several places – libs/pool/test, libs/type_traits/test, libs/units/test, etc.
Shouldn’t boost have one or the other? Either warnings are important enough to treat them as errors in the unit tests (in which case they should get fixed) or else they’re not that important and warnings-as-errors shouldn’t be enabled by default anywhere?
Personally, I like my stuff to be warning free, and in something as "core" as type_traits, any warning at all can be a real pain that gets repeated dozens of times each with 10 pages of instantiation back-trace, so I think it makes sense to enforce a no-warnings policy in that one case. In other libraries, and in particular if they have dependencies on other Boost libraries (even just testing dependencies) then trying to enforce a no-warning policy is probably a road to perdition. John.