This seems like utter madness.

In what world is $aref->@* clearer than @{ $aref }?

Maybe I'm getting old but I'm not seeing the benefit here.

You could even just write @$aref in your example.

Post deref can be more useful with more complex expressions like: $myobj->onemethod()->{blue}->anothermethod()->[4]->@* where you can read the thing in the order in which they happen (call onemethod, get the value at "blue", call anothermethod, get the value at 4, then deref), rather than @{ $myobj->onemethod()->{blue}->anothermethod()->[4] } where you read the steps from left to right, and the last one back on the left. I'd use a temp variable in both cases though.

Postderef can also help with slices where $some->{nested}{$complex{struct}}->@{qw<where I want more than one value>} is easier to read than @{$some->{nested}{$complex{struct}}}{qw<where I want more than one value>}. Again a temp variable would be a better idea in both cases IMHO.

When the poll was published I truthfully answered with "Never". However, since then I find myself checking whenever I write @{$stuff} whether it would be more readable as a postfix dereference. Eily already brought up one border case in Re^2: I use postfix dereferencing ..., but I'd agree with him that in this case an intermediate variable would be preferable.

Today I stumbled over another use case where I am now tempted to use postfix dereferencing: I'm pulling several attributes out of an object, some of which are array references... and I need copies of the arrays. In that case, scalars and arrays "line up" better with postfix dereferencing. SSCCE:

use 5.020;
use feature 'postderef';
package Object {
    use Moose;
    has string => (is => 'ro', isa => 'Str');
    has aref   => (is => 'ro', isa => 'ArrayRef');
};

my $object = Object->new(string => 'Hello World',
                         aref   => [1,2,3]
                     );

# Traditional dereferencing
my $string = $object->string;
my @list1  = @{$object->aref};

# Intermediate variable
my $string = $object->string;
my $aref   = $object->aref;
my @list2  = @$aref;

# Postfix dereferencing
my $string = $object->string;
my @list3  = $object->aref->@*;
[download]

What needs work in my opinion is the documentation in perlref. It claims that (emphasis mine) Postfix dereference should work in all circumstances where block (circumfix) dereference worked, and should be entirely equivalent. "Should work"? Except when it doesn't? I'd prefer not to rely on syntax which should work. A bit later it says: Note especially that $cref->&* is not equivalent to $cref->(), and can serve different purposes. I admit that I'm too lazy to work out the difference and have decided not to use the ->&* construct instead.

About that last point, $sub->&* would rather be equivalent to &$sub, meaning it passes the current value @_ to the subroutine (the comma after &$sub, is not a typo, it's to mark the fact that you can't pass parameters with the ->&* form):

perl -MData::Dump=pp -dEbug

Loading DB routines from perl5db.pl version 1.51
Editor support available.

Enter h or 'h h' for help, or 'perldoc perldebug' for more help.

main::(-e:1):   bug

  DB<1> $a = sub { say pp @_; say 'wantarray' if wantarray }

  DB<2> @_ = qw< Hello World >

  DB<3> $a->()
()
wantarray

  DB<4> $b = $a->();
()

  DB<5> $b = &$a,;
("Hello", "World")

  DB<6> $b = $a->&*;
("Hello", "World")
[download]

The whole postfix approach was cute when it was c = *p++ in C. Get the value pointed to by the pointer, then increment the pointer. Sure.

Turning an arrayref into an array (@{ $array_ref }, or @$array_ref), as has already been mentioned, is fine. Going to $array_rec->@* instead seems to obscure what's going on .. like you're giving directions, and saying, "Up ahead, turn right .. oh, but first, turn left.".

That's fine, now I'm aware, and can answer if it comes up in a job interview. And I'll avoid using it like the plague.

Alex / talexb / Toronto

Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.

(De-)referencing is one of the topics I need to look up frequently in the docs, so I am not yet prepared to (not) understand a second way of doing it...

I hadn't heard of it, but it does look useful for slices.

When my editor recognises the postfix defref syntax

Well, today I learned abut postfix de-referencing. I'm going to sound like a grumpy old man here, but I'm really not sure what it adds to the language, apart from providing another clever job interview question that I'm going to miss.

I'm still supporting 5.6.0, you insensitive clod!

Postfix dereferencing has been with us since at least 5.6. 5.20 simply extended it beyond array elements, hash elements and sub calls. Mini-Tutorial: Dereferencing Syntax

That's specificity at its finest, while also being purely pedantic. It's also honest and completely true.

This looks like a really useful feature. More ways to do a thing helps you understand the thing you do. One look at the Documentation and (de-)referencing seemed more like it's own operation, rather than something that needs to be done differently for each data structure or variable type or scoping function or Thing.

Perl 6 is object orientated, and this feature appears to be aligning Perl 5 with some of that kind of thinking. But objects in Perl 5 are not the same as objects in a fully qualified objective language. Though tends to be preferred for reasons of mnemonicisity and security and so on.

The perliness of this is that it is using method invocation to implement a (de-)referencing operation in a somewhat recursive manner. As to invoke a method on something, that thing needs to be a reference. So there's potentially also some auto-vivication at play here with the assignment capabilities.