in reply to Experimental push on scalar now forbidden

Change

push $rohanRoot->{'rohan2'}, $rohan1;

to

push @{ $rohanRoot->{'rohan2'} }, $rohan1;

Calling push with a reference as its first argument did not prove to be a good approach. You need to pass an array as the first argument to push.

Also, consider having your critical systems not auto-update and try to test your programs on a single system before upgrading.

Update: Also see tybalt89s answer above, which shows what the syntax was replaced by.

Replies are listed 'Best First'.
Re^2: Experimental push on scalar now forbidden
by KurtZ (Friar) on May 21, 2017 at 18:53 UTC
    Calling push with a reference as its first argument did not prove to be a good approach

    May I ask why?

      I did a bit of digging in the archives. I believe the original proposal for autoderef is this: perl #78656: Allow push/pop/keys/etc to act on references (this already contains a long discussion). The feature was introduced in v5.14 (documented as experimental, but standardized warnings for experimental features weren't added until later, Update: in v5.20).

      This P5P thread appears to be one of the discussions about the problems with the feature: Bug in auto-dereferencing in 5.14? My understanding is that there were lots of small problems with it, some philosophical but several practical, that added up to this being a contentious feature. Just to pick out two examples, again just based on my understanding from skimming the discussions: First, given that each, keys, and values can operate on both hashes and arrays (since v5.12), what does $x autovivify to in my $x; keys $x;? Second, what about blessed references that overload their dereferencing operations?

      Since part of the reasoning behind introducing autoderef was to make some expressions simpler (push @{$foo{bar}{quz}}, $x; became push $foo{bar}{quz}, $x;), i.e. getting rid of the need for circumfix @{} and %{} dereferencing, the Postfix Dereference Syntax that was first introduced in v5.20 took care of that particular point (push @{$foo{bar}{quz}}, $x; became push $foo{bar}{quz}->@*, $x;). It seems to me that the discussion then generally moved in the direction that the problematic autoderef could be removed in favor of postfix deref (e.g. perl #119437: autoderef, the implicit deref in push REF and others, the future of auto-deref), until that then happened in v5.24 together with postfix deref being taken out of experimental status as a replacement.

      (Update: See also perlexperiment.)

        Thanks a lot, especially for the summary! :)

        Very nice work haukex!

        Now that you mention it, I remember the whole auto-deref fiasco, and also recall having some long conversations about it now that you dug up the details.

        Nice work closing out this thread with such detail :)

      There have to be discussions as to the reasoning (typically, an experiment (certain operations such as push, pop etc on a scalar is one such experiment that made it into 5.14) don't work out. The majority of the time, a failure is due to a possible interference with future design considerations. This particular experiment was removed from 5.23 (dev track for 5.24).

      In this case, I haven't found out the discussions regarding any debates on this particular topic, but per perlexperiment for 5.24.0, it's clear that this feature was dropped for the Postfix Dereference syntax. tybalt89 provided an example of that, here.

      Of course, you can and always have been able to use the "circumfix operator" to push to a reference... push @{ $href->{aref} }, ...; or just a straight-up deref push @$aref, ...;.

      update: I said above: "The majority of the time, a failure is due to a possible interference with future design considerations."

      That may have been inaccurate, as I don't have statistics on the matter. Perl devs are under the order of perlpolicy, where the number one rule is to do their best to honour backwards-compatibility. Some of the experiments get downthumbed or footshot because something comes up that breaks things that used to work, is considered a "feature", and still need to work. My use of "majority" was wrong, as I truly don't know. I do know that at least some get written off due to future considerations, but I also know that some die due to breaking past compat, even if they live for a while.

        Thanks! Personally I never used it because I had too many problems with experimental features in the past.

        I haven't found out the discussions regarding any debates on this particular topic,

        But I'm still interested to know where the new syntax led to problems. :)