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

Reply via email to