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.
--John
