develooper Front page | perl.perl5.porters | Postings from February 2021

Re: undoing of auto-deref removal

Thread Previous | Thread Next
Ricardo Signes
February 28, 2021 17:31
Re: undoing of auto-deref removal
Message ID:
On Sun, Feb 28, 2021, at 2:21 AM, L A Walsh wrote:
> It seems all of the reasons against auto-deref were answered in-so-much 
> that that claims of ambiguity were shown not to exist.  For example, in
> the case of use of 'keys'.  Without autoderef, the language requires
> a perlvar of type ARRAY or HASH with a '@' or a '%' in front of it.
> Autoderef only supported the option of having a reference to something
> that would have had an '@' or a '%' in front of it.  Since perl always
> knows the type of vars having an '@' or '%' in front of, then
> a reference to either can automatically, and unambiguously always be
> assumed to be of type that would have had an '@' or '%'.
> So can I ask that it's removal be undone?

The short answer is: this just isn't happening.

I think, but am not sure, that you're a bit confused about the realities of the ambiguity of autoderef.  Some built-ins can work on both hashes and arrays.  These include "keys" and "each" and "values".  (I think that's it.)  Also, via overloading, a reference may be able to function as both a hash and array reference.  Consider this program:

use v5.14.0;
no  v5.16.0;

package Weird {
  use overload '@{}' => sub { [ 1, 2, 3, 4 ] },
               '%{}' => sub { { (a=>1, b=>2) } };

  sub new {
    my $val = "Meaningless.";
    bless \$val, 'Weird';

my $aref  = [ 1, 2, 3, 4 ];
my $href  = { a => 1, b => 2 };
my $weird = Weird->new;

say "A $_" for keys $aref;
say "H $_" for keys $href;
say "W $_" for keys $weird;

What should the "W" behavior be?  In reality, the decision was that to avoid ambiguity, this would be fatal.  That means that if you're going to allow things that provide an array ref or hash ref interface, but are not unblessed references, you must add the dereference yourself:  "... for keys @$weird" or "... for keys %$weird".  So the gain is small.  Meanwhile, "push $weird" would work, which sort of shunted keys/values/each into a second class position.  Some people were happy with this, sometimes because they thought that arrays should never have picked up keys/values/each.

The problem being solved was, basically, "circumfix dereferencing is a pain."  Writing "keys %$foo" is not so bad, but writing "keys  $foo->{0}[$x][$z->{index}]" and then realizing you forgot to wrap the expression in @{...} is more onerous.  This problem is *also* addressed by postfix dereferencing, and more generically, without ambiguity, and operating in all places instead of a few built-ins.

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