Re: [boost] Boost.Conversion - pre review request

Subject: Re: [boost] Boost.Conversion - pre review request
From: Gordon Woodhull (gordon_at_[hidden])
Date: 2011-07-08 22:10:14

Hi Vicente, all,

> I've been reworking the Boost.Conversion library
> 
> Documentation:
> http://svn.boost.org/svn/boost/sandbox/conversion/libs/conversion_ext/doc/html/index.html
> Sandbox :http://svn.boost.org/svn/boost/sandbox/conversion/

> Description:
> Boost.Conversion manages with generic extrinsic conversion between unrelated
> types. These conversion can be seen as implicit or explicit conversions.

I am excited to manage the Conversion review at the end of August.

It may be simple enough for us to say "extrinsic type-to-type conversion" since we both participated in the Boost.Convert review and have all those distinctions in mind...

But it might be confusing to potential reviewers and followers of Boost that in other "little c" conversion news this year:
* lexical_cast has received a new maintainer who is adding optimizations for type-to-type which overlap with Conversion
* Vladimir Batov's Boost.Convert was withdrawn.  I think it's fair to Ed Diener's excellent review report [1] to say that the library was not acceptable in its current form not because it didn't have the right features, but mostly because of syntax problems.  And because of confusion that its scope overlapped with lexical_cast, which I'm trying to avoid in the upcoming review!
* Jeroen Habraken is working on a Boost.Coerce library [2] which does more runtime-efficient string-to-type and type-to-string conversion using Spirit.

One clear distinction is that the proposed Boost.Conversion is not concerned with the special cases of string-to-type and type-to-string.  It provides a general framework for type-to-type conversion and will defer string conversions to lexical_cast or coerce depending how it is configured.  

IMHO lexical_cast is not the appropriate generic function to use for type-to-type conversion (when there is no text involved), and I am managing the review to evaluate whether Boost.Conversion is the right solution.  

Boost.Conversion learns from the use cases that were presented by Vladimir Batov in Boost.Convert and its review, and IIUC it now provides all the behaviors that were not string-specific, without the syntax problems.  Obviously, that also means no operator<<, so there's no way to specify formatting options if text is involved.  (Jeroen, if you're reading this, can you convert to/from e.g. hexadecimal with Coerce?)

So, Vicente, let's go over the Scope section of the documentation, quoted in your message.  This helps a lot, but it should also include comparisons and interactions with the libraries listed above, as well as Boost.NumericConversion.

> The conversion operator can not be overloaded with a free function on C++.
> In the past, there were some request to been able to overload the @c
> static_cast operator []. The author thinks that the language would be more
> uniform if this extrinsic overload would be possible.

> 
> The new operators
> could take the following form
> 
> operator Target(const Source& val);
> 
> explicit operator Target(const Source& val);
> 
> The assignment operator could also be overloaded by a free function with
> some limitations as described in []
> 
> Target& operator=(Target&, Source const&);
> 
> Boost.Conversion tries to provide a library emulation for this missing
> feature and shows some needed workarounds that are needed to take care of
> the current C++ semantics.

Okay, so it is a library demonstrating the usefulness of a possible language feature.  However, your intro should also argue the library's  usefulness up until C++20.  :-)

> In order to provide the needed functionality, two type traits are mandatory
> is_constructible and is_assignable. The library provide a first
> implementation of these type traits that works on compilers providing some
> specific features. The idea is that these type traits should be added to
> Boost.TypeTraits. 

Are they needed simply to enable/disable the corresponding function in Conversion, or does it also affect the behavior?

> When we don't have an automatic way to detect these traits, the library
> provide specialization for some std and boost types. If you agree the
> library could provide the specializations for all the standard types and
> optionally for some Boost types.
> 
> User working with compilers not supporting the definition of these traits,
> or users that need to make their code portable, will need to specialize
> these traits by hand for his types.

All good, but it probably doesn't belong in the intro.  As a library user I presume you will provide support for a good number of compilers in the best way you see fit.

> The review dates are 20th to 29th August. I would like to have some feedback
> before the review so I can have some time to make the library review ready.

I hope this is helpful and I'll provide more detailed feedback soon.

Cheers,
Gordon