I doubt that's documented or guaranteed behavior.
It's present in the
Inside Out objects documentation at least. And the
perlref doc states
Using a reference as a string produces [...] the numeric address expressed in hex.
Which is used to see if the two references refer to the same location. There's nothing that explictly states that a lexical variable will have a constant address for the duration of its scope though. And I didn't know that this was already broken by the experimental refaliasing, because I would expect that CPAN modules use constructs like
process(@a) unless $processed{\@a}; which would break if the address is not constant. At least refaliasing makes it explicit that you are "overwriting the reference", because
\@a=\@b; is not valid in "classic perl", so you're either going to guess what it does, or think it's a syntax error. Same goes with your declaration proposition. The declaration syntax wouldn't just be about type security, but rather about new features being a syntax error if used outside their scope.
I didn't mention globs because while they make it easy to have an array always be the thing a references refers to, they can't be used with lexicals alone. Once again though, this was for lack of knowledge that aliasing is possible between lexicals. I now know that your proposition can be implemented (or at least emulated) using existing features.
I still like $array being read-only better though, because it would make it possible to have a reference bound to your array for ease of use, without the side effects, or even misleading perl newcomers into believing that $array = [1..3]; overwrites the values of the array instead of creating a brand new one.
Edit: tr/$/&/ in html escape :)
