Front page | perl.perl5.porters |
Postings from July 2019
On Sat, Jul 13, 2019 at 5:21 PM Deven T. Corzine <deven@ties.org> wrote: > On Sat, Jul 13, 2019 at 5:03 PM demerphq <demerphq@gmail.com> wrote: > >> On Sat, 13 Jul 2019, 19:42 Deven T. Corzine, <deven@ties.org> wrote: >> >>> 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" >>> autovivification.. >>> >> >> >> I don't think we can change the default behaviour, on the other hand I >> think core should own 'no autovivification' and make it as efficient as >> possible. >> > > Would it be so bad, to change the default behavior -- perhaps with a > deprecation cycle? It's not like Perl releases *never* break existing > code. Here's a post from just last month about Perl 5.30 breaking existing > code due to deprecation of my() in false conditionals: > > > https://dev.to/mitchjacksontech/perl-5-30-deprecates-use-of-my-in-a-false-conditional-55bg > > Actually, I wonder if changing the autovivification behavior might > actually FIX more code than it breaks! (It's plausible, I think...) > Yes. Full stop. Tons of code relies on autovivification. -DanThread Previous | Thread Next