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