HaloO,

John M. Dlugosz wrote:
You want a way to declare the function to accept both lvalue and non-lvalue items, and determine at run-time whether it can write back to it.


Yes, but as a general feature. Any assignment checks the constraint
of the lvalue. A non-writeable lvalue is simply having an impossible
constraint. That amounts to "everything does lvalue upto a constraint".
So effectively everything becomes an lvalue.


The MMD matching solution does not require return type matching. The information "does this conform" is part of the parameter types.

  multi sub foo (Num $x is ro) { ... }
  multi sub foo (Num $x is rw) { ... }

The second is not a candidate if you pass a literal, a constant, whatever.

OK, this is the easy case insofar as the Num in the signature
does syntactic double duty in first constraining the type of the
input towards *more* specific types and then constraining the container
towards *less* specific types.

The second is considered a better match when it is a candidate by virtue of the ordering rules.

Where do you get the information from that the second is more
specific than the former? Consider

   constant Num $c = 3; # Num here is funny
   my       Num $n = 3;
   my       Int $i = 3;
   my       Any $a = 3;

And now $i is more specific than $n? Would a call to foo with $i
dispatch to the ro case? Is $a more specific than $n? Note that undef
is the only "value" that meets the impossible constraint. So calling
the rw foo with $i might store an undef. Not to mention the autocoercion
of Num to Int upon assignment. Do you expect the dispatch take that into
account as well? Consider

  multi foo (Int $x) {...}

Is this more specific than the second when called with $n? How
do 'is ref' and 'is copy' fit in your sort order? My reading is
that the parameter traits are *not* dispatch relevant. Therefore
your two multis are an error because of indistinguishable signature.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Reply via email to