I think the idea of "The expected semantics of &.() is that of a type 
coercion..." confuses the notion of function call and conversion.  If anything 
other than a Code object has one, it is acting as a functor, or function-like 
object.  The meaning of Dog(args) is seemingly a class method anyway, not a 
normal instance method.  It was elsewhere said that the type name as a listop 
indicates conversion.  I think that should be taken to mean that the compiler 
uses whatever form of conversion function is available.  I think $obj(args) 
should mean whatever I want it to mean, like any other function.  An (untyped) 
variable $obj can call &.() with the same syntax it does with an object of type 
Code, no problem.

We already use the method .new to mean "create one of these using these 
arguments".  Sometimes that =is= logically a conversion.  In C++ that is 
assumed by default.  So why make a different function with different syntax?

I propose that any method that is logically a "conversion" can be marked with a 
property to say so, and the implementation will draw upon those when asked to 
perform a conversion.

 our C multi method ^new (D $oldguy) is conversion<implicit> { ... }

(er, the default inherited .new doesn't prevent me from making a multi new in 
my class, right?)

Now I can say  $c = C.new($d);  and if I ever say $c = C $d; or my C $c = $d;  
it will know that this is the function to call.


Reply via email to