* mt1957 <mt1...@gmail.com> [2015-08-31 19:35]:
> I can not do the following;
> my Buf $b = 'abc'.encode;
> Type check failed in assignment to '$b'; expected 'Buf' but got 'utf8'
>
> But I can do this;
> my Buf $b = 'abc'.encode ~ Buf.new();
> Buf:0x<61 62 63>
>
> Does the concatenation convert utf8 into Buf? Will there be a problem
> when it is converted back to string with decode. I've tested a few
> simple utf strings which seem to decode right.
I’m not sure what exactly is going on, either, but a bit of digging in
the source reveals this much: utf8 is a class that does the Blob[uint8]
role, and Buf is a type-parametric role that does the corresponding Blob
role, and if I understand the code right then just asking for a generic
Buf gets you a Buf[uint8].
So, I’m slightly surprised that the type check fails, but I assume it’s
because of type variance, i.e. that a Buf counts as a subtype of Blob,
and you only have something that does Blob – but not Buf specifically.
Since the variable is typed as Buf specifically, the Blob you’re trying
to assign fails to pass the type check. That’s my guess.
In any case, if my understanding is correct then your fix is fine. But
it’s clumsier than need be. First of all there’s no need to concatenate
to cause an implicit coercion.
my Buf $b = Buf.new('abc'.encode);
And since you’re then assigning something of the same type you already
declared on the left, you can use the mutating method call operator to
omit the redundant class name:
my Buf $b .=new('abc'.encode);
Still, it would probably be better if somebody told the type checker
that Blobs coerce to Bufs trivially. Presumably then your original code
would work.
I don’t actually know what I’m talking about, though. Someone who does
in fact do Perl 6 will have to tell you whether I’ve just been running
my mouth randomly here.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
