Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote:
Actually, it only looks complicated while you think only on the callee
side.
No, in general it requires introducing a read-only proxy in front of the
container. This may be optimized away when it can be tracked at
compile-time, but that's certainly not "simple" as compared to not
having it nor the aliased item container at all.
Because when you take the caller side, you'll note that it builds
a capture to send to the call, and the capture is always a reference, so
the signature just makes sure that references becomes read-only. To
illustrate:
my $a = 1;
foo($a);
In this case, the capture sent must contain a direct reference to the
scalar held in '$a', so both signatures with "is ref" or signatures with
"is copy" can work.
So, if foo has the signature
sub foo($a is ref) {...}
it will be able to change the scalar outside &foo. If it is
sub foo($a) {...}
It will be a read-only access to that scalar
sub foo($a is rw) {...}
Works almost like "is ref", but encloses immutables into a container in
order to always provide rw semantics.
No, "is rw" does not like immutables. It will cause autovivification to
take place, but will not accept something that is not an lvalue such as
1 or "Hello" literals. This was just doubled-checked with S06, S09, and
discussion with Larry in #perl6. If Ra
<ruoso> rakudo: sub foo($a is rw) { $a += 1; say $a }; foo(1);
<p6eval> rakudo 77f9d7: OUTPUT«2»
that directly contradicts S06, which states "Otherwise the signature
fails to bind, and this candidate routine cannot be considered for
servicing this particular call." Doing otherwise affects the semantics
of MMD for allowing overloading based on whether the parameter is an
lvalue or not.
Somebody who works with rakudo could submit a bug, if it's not in there
already?
sub foo($a is copy) {...}
Is the completely opposite to "is ref", copying the actual value to a
new container.
Agreed.
So, it is not at all complicated, it's just oriented to the Capture, and
the capture provides semantics to the call that are not present in any
other language I'm aware of.
Complex or not in that sense, it complicates things in allowing the
value to be changed by another path. I think that is something we want
to avoid doing, not present as a feature. Much of my original post
concerns the actual meaning, not whether it is considered simple.
Since then, I see that it is useful for plural containers. We don't
want to copy them! But for items, why do we not even _have_ pass by
value? The compiler must assume the worst and can't optimize as well.
--John
