[boost] [config/multiprecision/units/general] Do we have a policy for user-defined-literals?

Subject: [boost] [config/multiprecision/units/general] Do we have a policy for user-defined-literals?
From: John Maddock (john_at_[hidden])
Date: 2013-04-27 08:29:43

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.