Thomas Sandlaà writes:
> Luke Palmer wrote:
> >So if you want things modified, you'd have to pass in a reference.
> >Arrays and hashes would not generally have this restriction, since we
> >pass references of those guys anyway.
>
> But I would really like to see a declaration of any possible modification
> in the interface of a sub.
Of course. We already have this.
> Otherwise you might find quite surprising things in your array, or
> terribly miss things. So after calling a sub that takes an array
> parameter the array argument should be in exactly the same state as
> before the call! And any attempt to use modifying operations in the
> sub should result in a compile time error. This is good for the
> optimizer as well.
>
> I don't see the above as a restriction. There are easy ways to achieve
> modifyable values by 'is copy' for temporary modifications in the sub
> and 'is rw' and 'is ref' for full access. But the caller clearly sees
> that in the signature.
Unless the caller can't see the signature, as is the case with methods.
That's the point of my thinking. Perl 5 had a performance (and a slight
semantic) problem with this. It had to construct lvalues out of all
arguments (for which that made sense) because the sub might modify them.
We'll still have to do that unless the "rw"-ness is marked somehow on
the caller's side.
> And the typechecker might throw exceptions when type safety can't be
> maintained through the sub call:
>
> sub foo (@a is rw) { @a[7] = "heaven" } # type of "" is Str
>
> my Int @i;
>
> foo( @i ); # type error/warning
Again, this can't be done unless you know the signature. And in fact,
we can't do type inference on methods unless we do type inference
everywhere, which we can't do if we want an autoloader.
Luke
