On Wednesday, March 12, 2003, at 11:07 AM, Damian Conway wrote:
Austin Hastings wrote:
In this case, I rather like the idea of being able to say sub foo(@a is Array of Int) {...} my @input = read_a_bunch_o_data(); foo(@input); Where the compiler will automatically "wrap" the @input array in a make-it-an-int converter. This, to me, is DWIM.
But to many others it's not DWIS ("Do What I Said"). To them, types are about compile-time checking of constraints on the run-time compatibility of data.
So they would argue that declaring C<foo> like that implies that any argument passed to C<foo> ought to guarantee that it already contains Ints, rather than specifying a (possibly unsuccessful) run-time coercion to ensure that condition. And many would argue that implicit coercions on typed parameters is one of the major *problems* with C++.
Agreed. It should do compile-time verification, not runtime.
That said, I still think there *might* be something to be said for compile-time 'hints' for explicitly _untyped_ values. Take the example:
sub foo(str $s) {...}
my str $a = 'blah'; # type 'str'
my $b = 'blah'; # untyped, but set to a constant 'str'
my $c = $a; # untyped, but set to a known typed 'str'
my $d = $a + $b; # untyped, but known to be of type 'str' foo($a); # OK
foo($b); # COMPILE ERROR
foo($c); # COMPILE ERROR
foo($d); # COMPILE ERRORWith strict typing, the last three lines are errors. But it is known that $b,$c,$d were all set to known C<str> values and have not since been altered. So the compiler *could* infer the type of these variables without them explicitly being stated, we *might* choose to catch those cases and make them non-errors. (You can actually track the 'type' hints quite a ways, if the operations you're doing produced typed values.)
That would allow the use of quickie untyped temporary variables. For example, if you have a little ten-line script that uses type-aware CP6AN subs, but yer a lazy slob.
Again, POMTC (percentage of me that cares), 50%. Not a showstopper. Just an idea.
MikeL
