Circle Calculator Help

[Steven Schveighoffer]

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