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

Subject: Re: [boost] Boost.Conversion - pre review request
From: Jeroen Habraken (vexocide_at_[hidden])
Date: 2011-07-09 02:52:34

Hi,

On 9 July 2011 04:10, Gordon Woodhull <gordon_at_[hidden]> wrote:
> 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?)

It isn't possible at the moment but it is to be re-added during the
Google Summer of Code. The syntax will probably look something like
coerce::as<int>("0x17", tag::hex());

> 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
>

If there are any questions regarding Coerce, please don't hesitate to
contact me either on- or off-list.

Regards,
Jeroen