Hiroki Horiuchi wrote:
My question is:
In current Rakudo,
my Int $i = '123';
causes a runtime error, not a compile time error.
How about in future Perl 6?
Generally speaking, in a dynamic language like Perl 6, one has to do the type
checking at runtime anyway, because we don't always have the information to do
it at compile time and because it is simpler. Runtime checks can always be
local while compile time checks may have to encompass an arbitrarily large
amount of other code that provides context.
Having just runtime checks is sufficient to begin with because they will still
always catch the errors. Compile time checks are then something you can add to
this in some, but not all, cases, and there are various degrees of diminishing
returns, where some compile time tests like the one you gave above would be very
easy to do but others are increasingly difficult.
An example of a problem that is more difficult to check at compile time is:
sub myop (Int $x, Int $y) {
return $x / $y;
}
Assuming that division by zero should be an error, a compile-time check won't
find a problem from just examining that code. Rather, a compile-time check
would have to check all the code that invokes myop, and any code that produces
the value to eventually give to $y, in order to know at compile time if the code
would try to divide by zero.
If all invocations of myop use a code literal for the $y argument, then this can
be checked at compile time, but if the argument is a variable, they have to look
further out.
-- Darren Duncan
