in reply to Re^12: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20 (context)
in thread use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20

Thanks! That is a much clearer explanation (to me, anyway).

shmem already dismissed my method-call counter example. I suspect your de-ref'ing a CODE ref counter example would be similarly dismissed. I still think that they both weaken the argument, though.

I was thinking I could channel shmem's point of view and prop up his argument. But when I tried to, I failed.

I tend to think that seeing @{...} tells me that I'm getting an array to operate on. Whether I'm in a scalar or list context impacts what value(s) that array provides. But that falls apart for @{...}[...] and @{...}{...}, as neither of them give me an array to operate on. They all three give me a list (of scalar values)... but only if used in a list context. So there is some commonality there, but it is hard to even articulate a single technical thing that is true of all three cases (unless you ignore context or decide to be sloppy in other ways).

You can certainly argue that ${...} always meant that you got a scalar (if you ignore using that scalar to invoke code), and the ${...}->@* now violates that old pattern.

But I just don't see a big problem with making the rather weak rule of "I have a guarantee for 1 of 3 (or maybe 2 or 4) sigils (if I ignore at least two whole types of dereferencing), and a similar thing that falls apart unless I'm sloppy for one more of the sigils" have yet another class of exceptions.

To me, the -> operator is what takes the scalar. There are lots of things -> can do with the scalar. The fact that the only two available data deref'ing things that can come after -> also returned scalars is not what I consider a huge precedent that should be preserved for all future data deref'ing things that can come after ->.

- tye