Folks, I've been experimenting with the new C++11 feature "user-defined-literals", and they're pretty impressive ;-) So far I've been able to write code such as: auto i = 0x1234567890abcdef1234567890abcdef_cppi; and generate value i as a signed 128-bit integer. It's particulary remarkable because: * It actually works ;-) * The value is generated as a constexpr - all evaluation and initialization of the multiprecision integer is done at compile time. * The actual meta-code is remarkably short and concise once you've figured out how on earth to get started! Note however my code is limited to hexadecimal constants, because it can't do compile time radix conversion - that would require a huge meta-program for each constant :-( This is obviously useful to the multiprecision library, and I'm sure for Units as well, but that leaves a couple of questions: 1) We have no config macro for this new feature (I've only tested with GCC, and suspect Clang is the only other compiler with support at present). What should it be called? Would everyone be happy with BOOST_NO_CXX11_USER_DEFINED_LITERALS ? 2) How should libraries handle these user defined suffixes? The essencial problem is that they have to be in current scope at point of use, you can never explicitly qualify them. So I suggest we use: namespace boost{ namespace mylib{ namespace literals{ mytype operator "" _mysuffix(args...); }}} Then users can import the whole namespace easily into current scope right at point of use: int main() { using namespace boost::mylib::literals; boost::mylib::mytype t = 1234_mysuffix; } 3) How should the suffixes be named? There is an obvious possibility for clashes here - for example the units lib would probably want to use _s for seconds, but no doubt other users might use it for strings and such like. We could insist that all such names added to a boost lib are suitably mangled, so "_bu_s" for boost.units.seconds, but I'm not convinced by that. Seems to make the feature much less useful? Many thanks in advance for your thoughts, John.