b) The argument passed here must be something that will definitely
not cause the program to crash and burn, and we'll verify that at
compile-time.
I'm arguing that the former is well-nigh useless, and that the latter is what large systems developers and optimizer writers have been begging for. Besides which, the latter gives you the former. If you don't care about compile-time type checking, declare the *parameter* as Scalar, and let it accept anything.
Module writers should always write their code to high standards of safety. Client code, OTOH, should be able to be more sloppy -- especially for one-liners. But I agree that (b) should be the goal: I agree run-time type checking is "well-nigh useless".
But, the definition of compile-time checking can be broad. Firstly, we should distinguish between things that are explicitly typed, and things that are not. If a user does not specify the type of a value, then the compiler should make a best-effort attempt to infer the type from what it does know. e.g.
sub foo () returns Int { 6 }
sub bar (Int $a) { print $a+1 }
...
my $a = foo;
bar($a);In this case, the user has chosen not to give an explicit type to $a, but a trivial dataflow analysis will determine that type. The default mode (in non-strict contexts) should be to infer the type.
I just re-read A1, the RFC:16 discussion. Larry seems to say that, outside of class definitions, strictness will not be the default. Such code is never very large (well, OK, I've seen some bad scripts: but hard cases make bad law), so we can afford to let the compiler do some work to do all the necessary inference ... and even insert coercion code if necessary. If performance becomes an issue, then the script writer will clean up the code.
A quick list of the possible cases -- the compiler might determine (via type inference) that a binding is:
definitely not safe: can't even be coerced -- always an error definitely safe, no corercion needed -- always OK definitely safe if we corerce -- OK in non-strict contexts undecidable -- error in strict contexts, else compile-time warning
Which brings us back to the question of what is coercable. I'd say that we should only permit implicit coercion where a user has not used explicit typing; but there should be a simple prefix operator to enable coercion of typed things. Perhaps the "splat" operator could serve here:
my Str $a = <>; my Int $b = $a; # Error -- $a is explicitly typed as Str my Int $c = $a.num # OK -- explicit corcion my Int $d = *$a; # OK -- splat permits implicit coercion
Dave. -- http://dave.whipp.name
