* 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/>