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