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

Re: undoing of auto-deref removal

Thread Previous | Thread Next
Veesh Goldman
February 28, 2021 08:18
Re: undoing of auto-deref removal
Message ID:
I don't see how you came to this conclusion.

Very simply, you are requesting a misfeatures. If you are writing a sub,
now you have to be defensive and check that the array-like thing that was
passed in isn't an object. You literally only gain bugs by subtly
disallowing Mojo::Collection objects to be passed in even though they are
INTENDED to be used as an array.

Your arguments about objects being opaque is also misled. Objects ARE
opaque, and therefore if they tell you that they can be used as an array,
it shouldn't matter if its blessed or not. The overloading IS part of its

On Sun, Feb 28, 2021, 09:21 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?
> Thanks!

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