Re: [boost] Formal Review Request: Boost.String.Convert

Subject: Re: [boost] Formal Review Request: Boost.String.Convert
From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2009-02-18 10:11:03

On Wed, Feb 18, 2009 at 04:45, Vladimir Batov <batov_at_[hidden]> wrote:
>> convert::to_string<wstring>,
>> convert::to_integral<int, rounding::down>,
>> convert::transcode_string<wstring, native_mbcs>, ...
>
> How about
>
>   convert::to<wstring>
>   convert::to<int, rounding::down>
>   convert::to<wstring, native_mbcs>
>
> I am serious. I actually like it. I understand you do not like my to/from
> but you are almost there. By eliminating the repetition (as for
> _string<wstring) we get a laconic and expressive (IMHO of course) interface.
> No need for various to_string, to_integral, transcode_string, etc. We get
> rid of the string namespace as well (it should be a plus isn't it?).

Actually, I agree with your point from the later email that once you
get rid of the suffixes, keeping the to is a waste.

I'm just not convinced that convert(-1) tells me that I should be
getting a std::string.  I think it's equally (if not more) plausible
that it should be some internationalizable string, be it std::wstring,
std::u8string, or what.

I also haven't thought through how the policies would need to work in
a general function.

>
> Can you meet me half-way? I'll "give" you the string namespace "back" and
> you get to keep "_string" as spare for something else... looks like you get
> two things :-)... in case I again embarassed myself with my English I am
> trying to be humorous here...
>

The smilie is deserved, but your English is fine here.

>> Although convert might allow mix-fix relatively nicely:
>> convert("5").to<int>(), ...
>
> It looks clever. However, with the default/failure parameter it will
> probably be
>
>   int i = convert("5").to(-1);
>
> Now it looks confusing... to me. Somehow I feel more comfortable with the
> example further up.
>

convert("5").to_typeof(-1) or convert("5").defaulting_to(-1) seem
quite reasonable.  They clearly give the choice between throwing and
non-throwing, too.  I like the possibility of allowing .into(outvar),
too, to avoid copyage (though rvalue refs may help with that).

This one's growing on me...