I agree that the presented alternatives are shorter and cleaner, but the aim of the library is not to provide new or better syntax for of flag-like types. Its main purpose is to strengthen existing code by turning logical errors, like - using unrelated enums with bitwise operators - wrong usage of negated flags (negative-bitmasks) - accidental usage of operator && instead of operator & into compilation errors. The library does this with minimal intervention: the definition of the enums is not changed, which implies that overload-resolution, template-instantiations, APIs, ... are not affected. The additional used "boost::flags::" functions from the example are not required. (Only scoped eums in Boolean contexts require an additional operator or function invocation)