TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:

Daniel Ruoso wrote:
Not really... 'does' is a composition operation, 'realises' would be
just a type annotation that doesn't change the actual composition.

OK, but that is not in the spec yet. To me that is like the
proposed 'like' operator but with the programmer taking full
responsibility. Like reinterpret_cast in C++.

I've not gotten that far yet, but I do envision a way to test for conformance rather than mix-in to create conformance and change things around. There might be a more primitive operation for doing than than binding a capture to a signature.

I also envision that this can give the compiler information that it uses to make a cached dispatch table, but this is not visible to the user. It just means that declaring your types, even "duck types" will not only give compile-time checking but speed up calling for that variable.

But either the HOW, the WHAT or both of $fp have to change
which implies that $y === $fp can't remain true after
$fp does Point. BTW, an interesting question is if a typed
binding could become invalid:

  subset AntiPoint of Any where {not .^does(Point)}

  my AntiPoint $ap := $fp; # fine for now

  $fp does Point; # now $ap is bound to a Point which
                  # violates the AntiPoint constraint

It's not different than

   my Int $y = 5;
   subset X of Int where { $_ < 5 }
   my X $x := $y;

The subset is part of the type of the item container. You alias it to something which is a different type of container. How can such aliasing ever be other than non-variant to be correct, unless the alias is read-only?

That's no different than defining a symbol with container type MyTiedItem and then trying to alias it to a plain Scalar. Type mismatch in the := operation.


Reply via email to