develooper Front page | perl.perl5.porters | Postings from July 2019

Re: [perl #133809] Perl silently adds a key to hash

Thread Previous | Thread Next
Deven T. Corzine
July 13, 2019 17:43
Re: [perl #133809] Perl silently adds a key to hash
Message ID:
On Sat, Jul 13, 2019 at 8:00 AM demerphq <> wrote:

> On Sat, 13 Jul 2019, 13:40 Leon Timmermans, <> wrote:
>> On Sat, Jul 13, 2019 at 12:46 PM demerphq <> wrote:
>> >
>> > It's the right thing because Larry said it was the right thing. Our
>> community depends on this understanding. And we really try to avoid debates
>> like this, Larry made a decision decades ago, and it's not subject to
>> review or change.
> I was speaking to a specific exchange which I believe is still covered by
> rule 1.
> Arguing that it's not the right decision is imo unhealthy for our
> community, arguing that regardless we should support something else as well
> isn't.

I wasn't aware of Larry making a Rule 1 call about this behavior -- I'm
sorry if I've disputed such a call, that certainly wasn't my intent.  To be
clear, I was NOT arguing that the current behavior is wrong.  It's easier
to implement, reasonable, logical, and certainly justifiable as the "right"
behavior, at least from an implementation perspective.

From another perspective -- the Perl programmer's DWIM perspective --
avoiding unnecessary autovivification for "read-only" usages would be (IMO)
more intuitive behavior which more likely matches the programmers intent,
and therefore might reasonably be viewed as "the right thing" from that
programmer's perspective.

The point I was trying to make was that describing this behavior as "the
exact right thing" is a bit over the top, particularly because the
inclusion of "exact" in that phrase implies that this is the only
reasonable "right" behavior and anyone who believes otherwise is ignorant
or misguided.  My objection was only about this phrasing in "perlreftut",
not the original decision itself.

Rule 1 stoped being a useful rule when we lost rule 2.
>> I do think it's possible to make this change. I very much think the
>> behavior that is being proposed is more intuitive (and tellingly I
>> haven't seen anyone argue otherwise). IMO there are three questions
>> that are relevant for deciding whether we should do this.
>> * What will break?
> Who knows? I have seen code that exploits this behaviour. But there is no
> way to know until we try it. Doesn't seem to me to be something we can
> change without a pragma.

Would you mind expanding on this, if you remember any details?  I'm having
trouble even imagining a hypothetical situation where the Perl programmer
would prefer unnecessary autovivification, so I'd love to hear more about
how and why someone wanted to exploit this behavior.

> * What does it cost us in complexity?
> I doubt that much.
> * What does it cost us in performance?
> I doubt that much.
> None of those questions (or their answers) involve invoking Larry.
> Agreed, but it's a different discussion than the one I responded to.
> Yves

I'm sorry, I didn't mean to cause any drama or dispute any decisions by
Larry under Rule 1.  My bad.

I would love to have the other discussion about whether the current
behavior could be changed (perhaps with a pragma) to avoid autovivification
except when actually required to store new data.  I do believe that most
Perl programmers would consider that more intuitive.  (Leon has a good
point that nobody is arguing otherwise!)

I suspect that many Perl programmers would appreciate such a change, since
code often needs to be added solely to prevent unwanted "read-only"


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About