Hello, This is a constantly nagging issue. There are a couple of places where nil is a PP define especially on the Mac: - objc.h #ifndef nil #define nil __DARWIN_NULL #endif and - MacTypes.h #ifndef nil #define nil NULL #endif So people complain because fusion uses nil as: namespace boost { namespace fusion { struct nil; }} So, nil is a reserved word in Objective-C. But this is C++! And that define is SUCH A BAD PRACTICE in C++! Some folks, like Paul Mensonides maintains a strong stance against this: I would just use #define nil nil as a sanity check and call it done. If the symbol is already defined, compilation error (or at least warning on overly permissive compilers). The symbol will be need to be undefined in between the inclusion of the two libraries. Workarounds like nil_ and (min)(...) just perpetuate the problem. Fix the root problem rather than treating the symptom indefinitely. Otherwise, where is the line drawn? Even if you can't provide a transparent fix (such as defining nil as a constant and min/max as functions), the backwards compatibility argument fails in the long run. The amount of effort required to make the necessary changes to existing code will eventually be outweighed by the effort to implement workarounds put into new code (as well as educate everyone that they are necessary)--especially in cases like these which can mostly be emulated in a way that causes most existing code to work. As I said over and over again, I'm listening and I would want to "fix" this issue if someone comes up with a reasonable (tested) patch that: 1) Detects the platform 2) Renames fusion::nil to something else (only for the affected platform) Yet, no-one wants to do this. Instead we get nasty remarks such as those found here: https://svn.boost.org/trac/boost/ticket/5010#comment:16 What do we do? I'm seeking for a resolution. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com