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

Subject: Re: [boost] [config/multiprecision/units/general] Do we have a policy for user-defined-literals?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-04-27 11:00:42

Le 27/04/13 14:29, John Maddock a écrit :
> 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 ?
This is fine. clang uses __has_feature(cxx_user_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;
> }
>
If http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3402.pdf is 
the final version accepted for C++14,  the standard will use, e.g.

namespace std {
namespace suffixes {
namespace chrono {

One of the advantages is that we can add some utilities. I helped Peter 
Sommerlad to port his reference implementation to Boost (See 
https://github.com/PeterSommerlad/UDLSuffixBoost/tree/master/boost/suffixes). 
There are some interesting utilities that make easier implementing 
suffixes. I guess it would like to name his library Boost.Suffixes.
This doesn't means  that we can not choose your option.
> 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?
>
>
I agree with Steven. We should choose the better suffixes for the 
specific domain independently of other suffixes on other libraries.

Best,
Vicente