On Wed, Feb 18, 2009 at 04:45, Vladimir Batov <batov@people.net.au> 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...