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):
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.
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'?
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.
Bye,
bearophile
