Front page | perl.perl5.porters |
Postings from March 2023
demerphq wrote:
>I dont see a problem here. The local is ending and we are putting it
>back to the original state.
The state immediately before the end of the local scope is a restricted
hash, which appears to preclude replacing that key. One can't make that
change in the ordinary way, and so I reckon the restoration via local
should also be unable to make that change. local restoration doesn't
have a general exemption from the language semantics.
If local restoration is exempt from immutability (indeed, if anything is
semantically exempt from immutability) then that destroys the usefulness
of immutability. It would be impossible to rely on readonly values not
changing, and that's a really useful thing to rely on. In practice, of
course, people would just rely on them not changing anyway, and get burned
when they actually change. It's a formula for widespread subtle bugs.
If you really want local restoration to be exempt, though, then this is
a bug (still present in your branch):
$ perl -lwe '%a = qw(aa bb cc dd); { delete local $a{aa}; Internals::SvREADONLY(%a, 1); print %a; } print %a'
ccdd
Attempt to access disallowed key 'aa' in a restricted hash at -e line 1.
> I think they are basically a failed experiment,
>except that every time I say that someone pops up and says "but I like
>them". :-(
I'd like to introduce straightforward read-only hashes. It shouldn't be
much work. To coexist alongside restricted hashes we'd need one extra
flag on HVs saying which kind of read-only it is if it's SvREADONLY.
> and IMO if we did consider it illegal it would be
>pretty confusing,
Isn't it more confusing to have a read-only object change its value?
> given a read-only value is not allowed to be updated or deleted,
>it also shouldn't be allowed to be localized.
I disagree. If local restoration is allowed to alter the state of a
read-only object then I reckon it's equally legitimate for the forward
side of localisation to change it. It's not making a change to the
object in the dynamic scope where it had that read-only state; it's just
temporarily hiding that state. I don't think that allowing localisation
to affect read-only objects makes for good semantics, but at least it
would be consistent semantics if dynamic scope boundary crossings were
free to do this in both directions.
-zefram
Thread Previous
|
Thread Next