Thanks for the report,
First to clarify: Nil.Int is *not* an error as you state, it's a warning and
you can suppress it with `quietly` block. A numeric Nil is 0, which is what you
get in return.
As for the problem you're trying to solve, you can use the following code. If a
Nil is returned from
prompt(), the `//` operator will change it to a `NaN`. Attempting to coerce a
NaN to a Nil is a Failure,
and so the `when Int` block won't match it.
given (prompt('int: ')//'NaN').Int {
when Int { say "you just entered the integer $_" }
default { say "that was totally not an integer" }
}
There's also val() routine: https://docs.perl6.org/routine/val with a caveat
that an empty string is 0.
With that said, there's no bug here, so I'm rejecting the ticket.
Thanks,
ZZ
On Mon Oct 24 08:19:21 2016, jkra...@mark17.net wrote:
> For most (all I've tested) types the method .Int works pretty much the
> same and as I'd expect: it either returns an Int or, if not possible
> because the invocant can't be converted to Int in a useful way or the
> invocant is not defined, it throws an exception. However Cool and
> classes that inherit from it and don't override the .Int method (namely
> Nil) behave differently in a potential harmful way: instead of throwing
> an exception, .Int here prints an error and returns 0. The problem with
> this is a) I can't check if a problem occured with try/CATCH, b) I can't
> check if the conversion succeeded by checking the return value, since 0
> is a valid and defined Int and c) it's very inconsistent with other
> types and makes me have to write extra checks prior to calling .Int.
> Random example:
>
>
> given try prompt('int: ').Int {
> when Int { say "you just entered the integer $_" }
> default { say "that was totally not an integer" }
> }
>
>
> This would normally allow me to prompt for a number and easily check if
> the input indeed was a valid number. The only problem is Nil (returned
> by prompt in case of EOF), which becomes 0, which is rather unexpected
> behavior in my opinion.
>
> Also finally, since .Int on Nil/Cool:U is already printing an error, I
> think it's obvious that calling .Int on them indeed *is* an error, so
> instead of printing that but continuing normally by returning 0 it
> should actually behave like there was an error, i.e. throw and exception
> so the programmer can deal with it using regular control flow
> (try/CATCH) and not make guesses about whether the invocant contained
> some value that was successfully converted to 0 or if the conversion
> failed.
