Vladimir Batov wrote: [snip] Just to restate my opinion, I don't quite like the "to" and "from" names. At least "from", in your notation, is confusing to me.
OK. What I got working (thanks to your help) is
int i = convert::to<int>(str, radix_ = 10); int i = convert::from(str, default_ = -1); int i = convert::from(str, (default_ = -1, radix_ = 10));
I understand the benefits of passing additional conversion parameters like 'radix_ = 10' down to the conversion *implementation*. However, I feel these parameters are of no value (and not accessible) to the "casual" user (as opposed to the conversion implementer)...
I don't understand what exactly you are trying to achieve. The conversion logic has to be concentrated somewhere, and I think it should be somewhere related to the source or the target type. In the nearby thread we were discussing conversion of user-defined types: namespace user { struct uuid; } user::uuid u; std::string str = convert::to< std::string >(u); Do you plan to support this use case? How would you suggest the "casual user" to extend the conversion to std::string str = convert::to< std::string >(u, uppercase_ = true); without support from the underlying conversion implementation for user::uuid?
unlike I/O Stream-based approach which allows the user to write his own manipulator and deploy it like
int i = convert::from(str, -1) >> my_special_formatter;
Do I understand correctly that the manipulators are used to format or parse the input by defining their streaming operators? If so, then how do the manipulators compose with each other? If I write: int i = convert::from(str, -1) >> my_special_formatter >> my_super_special_formatter; which one will be called?
Secondly, I kinda like the explicitness of
int i = convert::from(str, default_ = -1);
however, does it really add much (apart from verbosity) compared with
int i = convert::from(str, -1);
I do not feel the above line is the trickiest in the whole Boost so that we need to get out of our way to spell out every damn thing. What do you think?
I think that the default value should be immediately recognizable. The default_ keyword does that. There were alternative syntax suggestions that provided that, too. I think, we should strive to the cleanest interface we can provide.
That leads me to my question. Would that be sensible to have it as follows:
int i = convert::to<int>(str, (radix_ = 10, locale_= ...)); int i = convert::from(str, -1, (radix_ = 10, locale_= ...));
or you might have something else in mind?
If you declare conversion functions with Boost.Parameter macros, you will be able to get rid of the inner parenthesis: int i = convert::to<int>(str, radix_ = 10, locale_= ...); int i = convert::from(str, -1, radix_ = 10, locale_= ...); That way the default value really gets lost in the arguments. So, unless we move to an alternative syntax, I'm for making it a named parameter as well: int i = convert::from(str, default_ = -1, radix_ = 10, locale_= ...); The particular "default_" name, however, is not what I'm tied with.