On Tue, 26 Jun 2012 19:10:25 -0400, bearophile <bearophileh...@lycos.com>
wrote:
Steven Schveighoffer:
I agree with Andrei, there is no outlet for errors in the to!T
function, exception is the logical choice.
Maybe I was not clear enough, so let me explain a bit better.
What I don't like is to!int("15\n") to be seen as an error in the first
place.
I'd like it to ignore leading and trailing whitespace, as in Python
(stripping it automatically):
Right, but what if it's an error in your code if whitespace is present?
Then you have to check for whitespace and throw your own error.
I admit, that would likely be a rare occasion. But having both behaviors
should be possible.
int("15\n")
15
So it's not a matter of ignoring the errors, but ignoring that leading
and trailing whitespace.
On the other hand, if you write to!dstring("15\n") this shouldn't
strip away whitespace :-) So I understand Andrei motives too. To do that
you have to hard-code different behaviors inside to!() according to the
destination type. This is not so good.
Options should be possible. I think probably we could even accept them
like so:
T to(T, U, Opts...)(U u, Opts opts)
if(makesSenseAsToOpts!(T, U, Opts))
{
...
}
Then define options such as:
enum TrimWhitespace : bool {
Yes = true,
No = false
}
But I also agree with you that if you don't care, it should be possible
to ignore the errors without the cumbersome try-catch mechanism.
Something like:
to!(float, throw.No)(a)
or
toNoThrow!float(a)
What is it doing if you give it a wrong input string 'a'?
0. Similar to atoi That is, it consumes all leading numeric characters,
and ignores the rest.
I realize in hindsight this is no good for ignoring leading whitespace.
Probably an option to ignore whitespace is better.
This seems useful, but as you have seen it's different from what I was
looking for.
A non-throwing to!() may be handy to have:
nullableTo!int("XX") => empty Nullable
Nullable.get() is able to throw an exception. If you handle both empty
and full cases of a nullable the D compiler is not able to statically
infer that your code can't throw. You have to wrap that code into
catching instructions any way, if you want your whole function (that
uses nullableTo) to be nonthrow.
This might be a good option too, but couldn't we just do:
to!(Nullable!int)("XX")
Many possibilities exist.
-Steve
