On Tue, 26 Jun 2012 17:17:29 -0400, bearophile <bearophileHUGS@lycos.com> wrote:

> Steven Schveighoffer:
>
>> Oh, readln includes the newline by default, so to!float is choking on that.
>
> Similar things happen often. But Andrei says this is good, because it's more orthogonal. As Sting, I don't subscribe to this point of view. Orthogonality isn't more important than practicality.

I agree with Andrei, there is no outlet for errors in the to!T function, exception is the logical choice.

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)

-Steve

That must be why, I didn't import std.string!

Thanks!

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

On Tue, 26 Jun 2012 19:10:25 -0400, bearophile <bearophileHUGS@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

On Jun 26, 2012, at 4:40 PM, Steven Schveighoffer wrote:

> On Tue, 26 Jun 2012 19:10:25 -0400, bearophile <bearophileHUGS@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.

to!int(trim("5\n"))

no?

On Tue, 26 Jun 2012 19:44:34 -0400, Sean Kelly <sean@invisibleduck.org> wrote:

> On Jun 26, 2012, at 4:40 PM, Steven Schveighoffer wrote:
>
>> On Tue, 26 Jun 2012 19:10:25 -0400, bearophile <bearophileHUGS@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.
>
> to!int(trim("5\n"))
>
> no?

That was my original suggestion.  It fixes the problem, but can seem quite unintuitive to a developer that they have to do this.

Plus if it actually *is* an error for the string to have whitespace, you would want it to throw.  My point to bearophile is, we may want both options.

I can easily see someone using just to!int(userInput), and testing without ever putting in spaces, and then user does and the application blows up (quite needlessly).

-Steve

On 06/27/2012 01:40 AM, Steven Schveighoffer wrote:
> On Tue, 26 Jun 2012 19:10:25 -0400, bearophile
> <bearophileHUGS@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.
> ...

I think the default behaviour should be the behaviour that is wanted in the majority of cases.