[ISSUE: Type Inference]
Consider the following example:
class MyClass {...}
sub foo(MyClass $c) {...} my MyClass $a = MyClass.new;
my $b = $a; foo($a); # OK
foo($b); # ERROR!The issue here is that the variable C<$b> has not been typed -- or more accurately, it has been given a default type of C<Scalar>. So $b can store a MyClass, but it has not been _guaranteed_ to contain a MyClass, violating the typed signature of C<foo>.
This is potentially significant because for quick-and-dirty scripts, some programmers would prefer to not explicitly type every single variable they declare, but they would still like to be able to use modules that have been written to be type-aware.
NOTE that this issue only comes up when passing "untyped" vars like C<my $b>, C<my @b>, or C<my %b>. If a type _has_ been explicitly given, it's not type "inference", it's type "coercion", which should be considered separately.
[POSSIBLE APPROACHES]
1) If an "untyped" var is used for a typed parameter, it's a compile-time error. Broadly speaking, if you use type-aware subs, you must use type awareness everywhere.
The advantage of this approach is that in assures there will be no hidden runtime costs; if you want to take advantage of the *huge* speed increases of using strictly typed vars, you can just do it. The disadvantage is that you'd pretty much have to use types *everywhere* in your program, or *nowhere*, because the edge between them always introduces compile-time errors. This is especially troublesome when using library modules, for example.
2) If an "untyped" var is used for a typed parameter, invoke runtime type checking, either with or without a warning (according to a pragma?)
The advantage of this approach is that it will silently work; the disadvantage is that it could introduce *very* expensive runtime penalties if "accidentally" invoked, essentially nullifying the speed gains of typing.
3) If an "untyped" var is used for a typed parameter, a simple dataflow analysis is used to determine whether the compiler can guarantee that, at that point, an "untyped" var will _always_ contain values of a known, specific type. If so, the type is inferred (silently or with a warning, according to pragma?) Otherwise, it is a compile-time error.
The advantage is that it will silently work, and will present no runtime speed penalties. The disadvantage is that different implementations of Perl might have different levels of dataflow analysis, causing one-off code that was acceptable under a "smarter" analysis to be invalid if moved to a "dumber" analysis -- meaning either this has to be acceptable behavior of an implementation, or that we need to specify, as part of the language spec, the precise smartness of the analysis.
---
AFAICT, these are the *only* possible solutions to the problem. At last count, Larry was leaning towards #2. Damian was countering with #1. Some Lowly Grubs were suggesting #3. Am I missing anything?
I think we can decide _this_ issue independently of coercion issues, yes?
MikeL
