Skip Menu |
Report information
Id: 119437
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: rjbs <rjbs [at] cpan.org>
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: low
Type: unknown
Perl Version: (no value)
Fixed In: (no value)



Subject: [EXPERIMENT] autoderef, the implicit deref in push REF and others
Date: Thu, 22 Aug 2013 21:46:56 -0400
To: perlbug [...] perl.org
From: Ricardo Signes <rjbs [...] cpan.org>
Download (untitled) / with headers
text/plain 1.3k
Perl 5.14.0 introduced this behavior, described in perl5140delta as: Array and hash container functions accept references Warning: This feature is considered experimental, as the exact behaviour may change in a future version of Perl. All builtin functions that operate directly on array or hash containers now also accept unblessed hard references to arrays or hashes: [table] This allows these builtin functions to act on long dereferencing chains or on the return value of subroutines without needing to wrap them in "@{}" or "%{}": The behavior of autoderef changed between David Golden's original work and the final shipped product. Specific questions: * do we revert the behavior changes, at least in some cases? * do we add an 'experimental' warning for perl 5.20 if the experiment isn't "accepted" yet by then? * does this feature stick around if postfix deref is added On the third point, my current thought is that it seems like removing it just because a maybe-better form came around is going to lead to the same kind of groaning that we've gotten with the addition of warnings for ~~ in perl 5.18.0. Is it worth that? Current thoughts on *that*: I really don't know. It's not like the feature will not be useful anyway... Anyway, the general question is the same as any other [EXPERIMENT] ticket: What are the criteria for accepting or rejecting this experiment? -- rjbs
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 785b
On Thu Aug 22 18:47:31 2013, rjbs wrote: Show quoted text
> What are the criteria for accepting or rejecting this experiment?
For acceptance: • Remove The Unicode Bug; i.e., that changes to the ‘type’ of the argument (for various meanings of ‘type’, such as blessedness [bliss?]) do not change what the operator does. Without that, it causes compatibility problems for modules that want to start returning blessed array refs instead of the unblessed ones they used to return, etc. • If necessary after fixing that, extend the prototype syntax so that it can describe the actual syntax of these functions, so that we can make &CORE::shift work. At one point I suggested \. for a reference to any scalar expression, so shift would have (;\[.@]). -- Father Chrysostomos
Subject: Re: [perl #119437] [EXPERIMENT] autoderef, the implicit deref in push REF and others
Date: Fri, 23 Aug 2013 08:26:26 +0100
To: perl5-porters [...] perl.org
From: Nicholas Clark <nick [...] ccl4.org>
Download (untitled) / with headers
text/plain 1.7k
On Thu, Aug 22, 2013 at 06:47:31PM -0700, Ricardo SIGNES wrote: Show quoted text
> Specific questions:
Show quoted text
> * does this feature stick around if postfix deref is added > > On the third point, my current thought is that it seems like removing it just > because a maybe-better form came around is going to lead to the same kind of > groaning that we've gotten with the addition of warnings for ~~ in perl 5.18.0. > Is it worth that? Current thoughts on *that*: I really don't know. It's not > like the feature will not be useful anyway...
Assuming that postfix deref works, and works out, I certainly think that we should discourage the use of the autoderef syntax, because postfix deref will work everywhere that arrays and hashes are expected. I find the (necessarily) limited availability of postfix deref to be confusing - if I can autoderef on push, how come I can't autoderef on foreach? [1] I don't think that there will be anywhere near as much grousing 1) if a replacement is available 2) because it's not widely used, partly because unlike smartmatch it doesn't offer functionality available in any other form, but it costs you backwards compatibility. I can't find many uses, eg: http://grep.cpan.me/?q=%5E%5B%5E%23%5Cn%5D*%5Cbpush%5Cs*%5C%24 (about half of which are false positives. That query has been refined - it also likely drops a couple of real uses, but strips out a lot more false positives) My assumption is that if a more general, more powerful [2] replacement is available, maintained code would migrate to it. Nicholas Clark 1: Yes, I know the answer. But I have to *think* about it. "This should work here too? Oh wait, not it doesn't, because no it can't" 2: Doesn't fall foul of the bugs that sprout notes, some of which I think might be intractable.
CC: perl5-porters [...] perl.org
Subject: Re: [perl #119437] [EXPERIMENT] autoderef, the implicit deref in push REF and others
Date: Fri, 23 Aug 2013 06:57:10 -0400
To: Nicholas Clark <nick [...] ccl4.org>
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Download (untitled) / with headers
text/plain 439b
* Nicholas Clark <nick@ccl4.org> [2013-08-23T03:26:26] Show quoted text
> Assuming that postfix deref works, and works out, I certainly think that we > should discourage the use of the autoderef syntax, because postfix deref > will work everywhere that arrays and hashes are expected. I find the > (necessarily) limited availability of postfix deref to be confusing - if I
^^^^^^^- I think you mean auto- -- rjbs
Download signature.asc
application/pgp-signature 490b

Message body not shown because it is not plain text.

Subject: Re: [perl #119437] [EXPERIMENT] autoderef, the implicit deref in push REF and others
Date: Fri, 23 Aug 2013 14:17:11 +0100
To: perl5-porters [...] perl.org
From: Nicholas Clark <nick [...] ccl4.org>
Download (untitled) / with headers
text/plain 791b
On Fri, Aug 23, 2013 at 06:57:10AM -0400, Ricardo Signes wrote: Show quoted text
> * Nicholas Clark <nick@ccl4.org> [2013-08-23T03:26:26]
> > Assuming that postfix deref works, and works out, I certainly think that we > > should discourage the use of the autoderef syntax, because postfix deref > > will work everywhere that arrays and hashes are expected. I find the > > (necessarily) limited availability of postfix deref to be confusing - if I
> > ^^^^^^^- I think you mean auto-
I think I did too. Thanks for spotting this. use more 'coffee'; # or something like that* Nicholas Clark * says the hypocrite who is usually drinking decaf. Although not *right* now, as this afternoon my coffee is provided by http://validad.com/ (whom, I think, are hiring)
CC: bugs-bitbucket [...] rt.perl.org
Subject: Re: [perl #119437] [EXPERIMENT] autoderef, the implicit deref in push REF and others
Date: Fri, 23 Aug 2013 12:59:08 -0400
To: perl5 porters <perl5-porters [...] perl.org>
From: Eric Brine <ikegami [...] adaelis.com>
Download (untitled) / with headers
text/plain 361b
On Thu, Aug 22, 2013 at 9:47 PM, Ricardo SIGNES <perlbug-followup@perl.org> wrote:
Show quoted text
What are the criteria for accepting or rejecting this experiment?

I'm still opposed to it on the grounds that it only works for some references. C<push $ref, $a;> doesn't work for blessed arrays or objects with overloaded @{}, so using it isn't forward-compatible.

- Eric

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 820b
On Fri Aug 23 09:59:45 2013, ikegami@adaelis.com wrote: Show quoted text
> On Thu, Aug 22, 2013 at 9:47 PM, Ricardo SIGNES > <perlbug-followup@perl.org>wrote: >
> > What are the criteria for accepting or rejecting this experiment? > >
> > I'm still opposed to it on the grounds that it only works for some > references. C<push $ref, $a;> doesn't work for blessed arrays or objects > with overloaded @{}, so using it isn't forward-compatible.
As I’ve been saying from the outset: If push $scalar always implies push @{ $scalar } (without the scope) and keys $scalar always implies %{ $scalar }, this problem goes away. It also makes ‘keys foo’ consistent with ‘keys $scalar’, so there is no longer any reason to deprecate what will no longer be a special case (which strict subs catches anyway). -- Father Chrysostomos
CC: perlbug-followup [...] perl.org
Subject: Re: [perl #119437] [EXPERIMENT] autoderef, the implicit deref in push REF and others
Date: Sat, 24 Aug 2013 02:18:08 +0200
To: perl5-porters [...] perl.org
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Download (untitled) / with headers
text/plain 795b
* Father Chrysostomos via RT <perlbug-followup@perl.org> [2013-08-23 20:15]: Show quoted text
> As I’ve been saying from the outset: If push $scalar always implies > push @{ $scalar } (without the scope) and keys $scalar always implies > %{ $scalar }, this problem goes away. It also makes ‘keys > foo’ consistent with ‘keys $scalar’, so there is no longer any reason > to deprecate what will no longer be a special case (which strict subs > catches anyway).
That is the only form in which I find this feature viable. The current form is value-polymorphic which just never ever works in Perl 5, but if it were monomorphic it could stay. If that gets no votes, by next choice is to chuck it out – even now, but especially after postfix deref. -- Aristotle Pagaltzis // <http://plasmasturm.org/>
Subject: Re: [perl #119437] [EXPERIMENT] autoderef, the implicit deref in push REF and others
Date: Fri, 23 Aug 2013 20:39:30 -0400
To: p5p <perl5-porters [...] perl.org>
From: David Golden <xdg [...] xdg.me>
Download (untitled) / with headers
text/plain 1.7k
On Thu, Aug 22, 2013 at 9:47 PM, Ricardo SIGNES <perlbug-followup@perl.org> wrote: Show quoted text
> * do we revert the behavior changes, at least in some cases? > * do we add an 'experimental' warning for perl 5.20 if the experiment isn't > "accepted" yet by then? > * does this feature stick around if postfix deref is added
There are mixed solutions as well: * make pure array functions (push/pop/shift/unshift/splice) auto-deref (even on blessed objects) because they are unambiguous * eliminate auto-deref of any kind for mixed hash/array functions because of the ambiguity Because of the ambiguity of keys/values/each, we're always going to disappoint/surprise somebody. The current approach of allowing only unblessed objects seems a decent compromise, as does changing the behavior of keys/values/each on a reference — blessed or unblessed — to always be %{} which is probably 99% of cases. But not matter what, someone is going to grumble about whatever choice we make, even if it's "works for push, but not for keys". In hindsight, I wish we had said keys($ref) is always keys(%$ref). I think that might annoy people but is more useful and less likely to surprise people than having keys($object) fail. (I assume at this point that deprecating keys/values/each on arrays and replacing them with array-specific functions is off the table.) Ultimately, I'd hate to see the baby thrown out with the bathwater because of an edge case. I think this decision is somewhat orthogonal to postfix dereference, but I wouldn't cry if we got that and lost auto-dereference. It was our original inability to converge on postfix dereference that inspired me to figure out auto-dereference in the first place. David -- David Golden <xdg@xdg.me> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg
CC: p5p <perl5-porters [...] perl.org>
Subject: Re: [perl #119437] [EXPERIMENT] autoderef, the implicit deref in push REF and others
Date: Fri, 23 Aug 2013 23:03:06 -0500
To: David Golden <xdg [...] xdg.me>
From: Brad Gilbert <b2gills [...] gmail.com>
Download (untitled) / with headers
text/plain 2.1k
On Fri, Aug 23, 2013 at 7:39 PM, David Golden <xdg@xdg.me> wrote: Show quoted text
> On Thu, Aug 22, 2013 at 9:47 PM, Ricardo SIGNES > <perlbug-followup@perl.org> wrote:
>> * do we revert the behavior changes, at least in some cases? >> * do we add an 'experimental' warning for perl 5.20 if the experiment isn't >> "accepted" yet by then? >> * does this feature stick around if postfix deref is added
> > There are mixed solutions as well: > > * make pure array functions (push/pop/shift/unshift/splice) auto-deref > (even on blessed objects) because they are unambiguous > * eliminate auto-deref of any kind for mixed hash/array functions > because of the ambiguity > > Because of the ambiguity of keys/values/each, we're always going to > disappoint/surprise somebody. The current approach of allowing only > unblessed objects seems a decent compromise, as does changing the > behavior of keys/values/each on a reference — blessed or unblessed — > to always be %{} which is probably 99% of cases. But not matter what, > someone is going to grumble about whatever choice we make, even if > it's "works for push, but not for keys". > > In hindsight, I wish we had said keys($ref) is always keys(%$ref). I > think that might annoy people but is more useful and less likely to > surprise people than having keys($object) fail. > > (I assume at this point that deprecating keys/values/each on arrays > and replacing them with array-specific functions is off the table.) > > Ultimately, I'd hate to see the baby thrown out with the bathwater > because of an edge case. > > I think this decision is somewhat orthogonal to postfix dereference, > but I wouldn't cry if we got that and lost auto-dereference. It was > our original inability to converge on postfix dereference that > inspired me to figure out auto-dereference in the first place. >
I kind of like that I can have a subroutine like this that will work whether someone gave it an array ref, or a hash ref sub say_kv{ my($ref) = @_; my @keys = keys $ref; my @values = values $ref; while( @keys ){ say shift(@keys), "\t", shift(@values); } } That being said, I have yet to come up with an example that isn't a solution looking for a problem.
CC: David Golden <xdg [...] xdg.me>, p5p <perl5-porters [...] perl.org>
Subject: Re: [perl #119437] [EXPERIMENT] autoderef, the implicit deref in push REF and others
Date: Sat, 24 Aug 2013 08:10:54 -0300
To: Brad Gilbert <b2gills [...] gmail.com>
From: Brian Fraser <fraserbn [...] gmail.com>
Download (untitled) / with headers
text/plain 2.4k
On Sat, Aug 24, 2013 at 1:03 AM, Brad Gilbert <b2gills@gmail.com> wrote:
Show quoted text
On Fri, Aug 23, 2013 at 7:39 PM, David Golden <xdg@xdg.me> wrote:
> On Thu, Aug 22, 2013 at 9:47 PM, Ricardo SIGNES
> <perlbug-followup@perl.org> wrote:
>> * do we revert the behavior changes, at least in some cases?
>> * do we add an 'experimental' warning for perl 5.20 if the experiment isn't
>>   "accepted" yet by then?
>> * does this feature stick around if postfix deref is added
>
> There are mixed solutions as well:
>
> * make pure array functions (push/pop/shift/unshift/splice) auto-deref
> (even on blessed objects) because they are unambiguous
> * eliminate auto-deref of any kind for mixed hash/array functions
> because of the ambiguity
>
> Because of the ambiguity of keys/values/each, we're always going to
> disappoint/surprise somebody.  The current approach of allowing only
> unblessed objects seems a decent compromise, as does changing the
> behavior of keys/values/each on a reference — blessed or unblessed —
> to always be %{} which is probably 99% of cases.  But not matter what,
> someone is going to grumble about whatever choice we make, even if
> it's "works for push, but not for keys".
>
> In hindsight, I wish we had said keys($ref) is always keys(%$ref).  I
> think that might annoy people but is more useful and less likely to
> surprise people than having keys($object) fail.
>
> (I assume at this point that deprecating keys/values/each on arrays
> and replacing them with array-specific functions is off the table.)
>
> Ultimately, I'd hate to see the baby thrown out with the bathwater
> because of an edge case.
>
> I think this decision is somewhat orthogonal to postfix dereference,
> but I wouldn't cry if we got that and lost auto-dereference.  It was
> our original inability to converge on postfix dereference that
> inspired me to figure out auto-dereference in the first place.
>

I kind of like that I can have a subroutine like this that will
work whether someone gave it an array ref, or a hash ref

    sub say_kv{
      my($ref) = @_;
      my @keys = keys $ref;
      my @values = values $ref;
      while( @keys ){
        say shift(@keys), "\t", shift(@values);
      }
    }


Or even better:

    sub say_kv{
      my($ref) = @_;
      while( my ($k,$v) = each $ref ){
        say "$k\t$v"
      }
    }

each $arrayref is the only thing I would miss if this were yanked out.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 210b
This experiment has been deemed unsuccessful, and was removed as of commit 262309092c2de925e7ae4a527174f8dc2a0ec7b7 (first released as Perl 5.23.1 on 20 July 2015). -- Aaron Crane ** http://aaroncrane.co.uk/


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org