: > multi foo (@a is Array of int) {...}
: >
: > my int @a = baz(); # is Array of int
: > my @b = baz(); # is Array of Scalar
: >
: > foo(@a); # @a is typed correctly, so OK
: > foo(@b); # @b is not explicitly typed as C<int>; OK or FAIL?
: : Fails.
: : Because:
: : not (Array of Scalar).isa(Array of int)
: : Which in turn is because:
: : not Scalar.isa(int)
I dunno. I can argue that it should coerce that. It'll certainly be able to coerce a random scalar to int for you, so it's not a big stretch to coerce conformant arrays of them. On the other hand, it's likely to be expensive in some cases, which isn't so much of an issue for single scalars/ints/strs.
Hmmmm. I guess it depends whether we treat type specifications as constraining the actual arguments, or restricting the interface of the formal parameters.
That is, does:
multi foo (@a is Array of int) {...}
mean:
"Don't let them pass anything but an
Array of int-or-subclass-of-int"or does it mean:
"Let them pass Array of (anything)
and then treat the anythings as ints"For my money, the former (i.e. compile-time type strictness) makes more sense under pass-by-reference semantics, whereas the latter (i.e. run-time type coercion) is more appropriate under pass-by-copy.
Damian
