int men = convert_to<string, int>(str);
Just to clarify. You probably meant one of the below: int men = convert_to<int>(str); int men = convert_from<string, int>(str); int men = convert<string, int>(str);
would propose, rather than having a default "fallback" value to provide two overloads for convert: one with two parameters where you can provide the fallback value, and the other, one-parameter, that would indicate that you want to throw an exception on failure. Yo do not loose much of your original interface, because you can write more explicitly:
int men = convert_to<string, int>(str, 0);
Yes, I tend ot agree. Requiring an explicit default seems clearer and less ambiguous. Once you mentioned that int men = convert_to<int>(str); looks very unsafe to me. It's highly unlikely 0 (or any default-constructed object) would be a good failure indicatior... especially snicked in "under the table".
I find it better because: 1. It forces the writer to type more clearly his intentions. (Or explicitly confirm that he is aware that the string may not be convertible to int.) 2. Releaves you from providing the throw_t argument altogether. This in turn removes the possibility of writing:
convert<string, int>(str, -1) >> throw_t(); // What does -1 mean here?
That "-1" indeed looks kind of out of place, doesn't it? :-) And 'yes', your arguments make a lot of sense to me. So, to summarize we are moving to the original lexical_cast behavior int i = convert_to<int>(str) // throws on failure int i = convert_from<string, int>(str, -1) // returns -1 on failure int i = convert_from(str, -1) // the same as above and throw_t scrapped. Any objections? V.