> 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.
'is copy' is pass-by-value... remember everything in Perl 6 is a reference, of sorts. Pass-by-value of the reference is covered by 'is ref'. A more useful variant of that being 'is rw', which gives you an extra assurance with its lvalue checking that the user's not giving you something that's going to explode when you try to modify it. Pass-by-value of the thing the reference points to is covered by 'is copy', which is the semantics people would generally expect when they hear 'pass-by-value'. Pass-by-reference-but-don't-accidentally-change-what-it-points-to is covered by the default case or 'is readonly'. This seems to me to be the ideal - we don't copy huge values around when the user doesn't need them, but we also don't have hugely dangerous mutable parameters by default (they should be extremely explicit for the user of an API). Most of the time, there won't be another path where the value could change. Under a threaded model allowing shared variables, sure it could be changed by another thread, but hopefully you're under lock there. If a user of your API contrives to make it change while you're running, that's their own foot they've just shot, because they can look at the signature and know the semantics of the parameter passing being used and know that if they change the value externally before you return Bad Things Could Happen. Matthew
