Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote:
Actually, it only looks complicated while you think only on the callee
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

 my $a = 1;

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


Reply via email to