Oh goody, two with one blow: --- Damian Conway <[EMAIL PROTECTED]> wrote: > Larry wrote: > > > : > 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.
I saw a description in A6 saying that an Array of Foo was basically a function which mapped int to Foo. That being the case, a coercive @scalars -> @ints "cast" used to translate an array parameter would really be a "wrapped" (function mapping ints to scalars) whose wrapper converted the returned result to ints. Is there going to be some generic way to do this? That is: Can I say SomeType @a; # extern, anyone? sub SomeType2int(int) returns int { my Some $some = call; return 0 + $some; } @a.wrap(SomeType2int); And having said that, then call: sub b(@input is Array of int) {...} b(@a); > > 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. You're treading dangerously close to the S&M line there... Does it make sense to say C<use strict params;> for this stuff? =Austin