
On May 7, 2005, at 3:50 AM, Kevlin Henney wrote:
However, when I consider what the most common use of a defaulted value would likely be, based on my own experience of similar features, other library designs and indeed your example above, it appears that in the event of non-conversion the explicitly default constructed value of the target type is the most common use. Creating an interface for that would be somewhat easier.
There are essentially three practical options for doing this, as I see it (a couple of others come to mind, but don't qualify as being in line with the existing design):
(1) Provide a wrapper type for the source on which lexical_cast is overloaded and will handle non-conversion separately, eg lexical_cast<T>(defaulted(a)) or lexical_cast<T>(nonthrowing(a)).
(2) Specify a target type that indicates a non-throwing outcome. The following suggestion has come to me from a colleague of Thomas Witt's: lexical_cast< optional<T> >(a).
(3) Define another cast-like function that is specifically named, eg nothrow_lexical_cast<T>(a).
In terms of simplicity and directness my preference is for (3), although I am not wed to the name. I would be interested to hear any thoughts on this.
Personally, I think there is a need to to specify the default value, rather than rely on the default constructed value. For example: int httpPort = convert_to<int>(aString, 80); Maybe that can be done in similar vain to (1) or (2): int httpPort = lexical_cast<int>(default_value<int>(aString, 80)); I don't know templates well enough to know if that's possible. Seems like the implementation would need to convert 80 into a string, and then back to an int, though, as default_value would need to return a string in the above example, right? -Dave