Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

List slice *sometimes* ignores undefined items #12335

Closed
p5pRT opened this issue Aug 19, 2012 · 68 comments
Closed

List slice *sometimes* ignores undefined items #12335

p5pRT opened this issue Aug 19, 2012 · 68 comments

Comments

@p5pRT
Copy link

p5pRT commented Aug 19, 2012

Migrated from rt.perl.org#114498 (status was 'resolved')

Searchable as RT114498$

@p5pRT
Copy link
Author

p5pRT commented Aug 19, 2012

From jrw32982@yahoo.com

@​x = ( (2)[0,1,2] );
@​y = ( (2)[  1,2] );
use Data​::Dumper;
print Dumper \@​x, \@​y;

produces​:

$VAR1 = [
          2,
          undef,
          undef
        ];
$VAR2 = [];

This seems inconsistent.  The first result (for @​x) was expected. The second (for @​y) wasn't.

I have tested this on linux ActivePerl from 5.8 through 5.16 with identical results.

@p5pRT
Copy link
Author

p5pRT commented Aug 21, 2012

From @jkeenan

On Sun Aug 19 08​:27​:12 2012, jrw32982@​yahoo.com wrote​:

@​x = ( (2)[0,1,2] );
@​y = ( (2)[� 1,2] );
use Data​::Dumper;
print Dumper \@​x, \@​y;

produces​:

$VAR1 = [
��������� 2,
��������� undef,
��������� undef
������� ];
$VAR2 = [];

This seems inconsistent.� The first result (for @​x) was expected. The
second (for @​y) wasn't.

I don't think it's particularly inconsistent. In the first case the
slicing operation finds a defined element in the 0-index position of the
RH and assigns it to the array on the LH, and then (I suppose) proceeds
to auto-vivify. In the second case, the slicing operation finds no
element in the 0-index position, has nothing to assign, and stops there.

If anything, I think the second case is more intuitively plausible than
the first.

I couldn't find anything in Camel book 3rd or 4th edition that clarifies
this definitively.

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

p5pRT commented Aug 21, 2012

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Aug 21, 2012

From @cpansprout

On Sun Aug 19 08​:27​:12 2012, jrw32982@​yahoo.com wrote​:

@​x = ( (2)[0,1,2] );
@​y = ( (2)[� 1,2] );
use Data​::Dumper;
print Dumper \@​x, \@​y;

produces​:

$VAR1 = [
��������� 2,
��������� undef,
��������� undef
������� ];
$VAR2 = [];

This seems inconsistent.� The first result (for @​x) was expected. The
second (for @​y) wasn't.

I have often relied on the fact that list slices return nothing for
nonexistent elements. But I have usually used a single index.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Aug 30, 2012

From @ap

* James E Keenan via RT <perlbug-followup@​perl.org> [2012-08-21 03​:55]​:

I don't think it's particularly inconsistent.

It is completely inconsistent with the way slices work in every other
case I can think of, and very surprising. This is a bug that should be
fixed. It has the distinct smell of an implementation accident.

@p5pRT
Copy link
Author

p5pRT commented Aug 30, 2012

From @ikegami

On Tue, Aug 21, 2012 at 3​:26 AM, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

I have often relied on the fact that list slices return nothing for
nonexistent elements.

Except they don't. Sometimes they return nothing, sometimes they return
undef.

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2012

From rick@bort.ca

On Aug 31 2012, Aristotle Pagaltzis wrote​:

* James E Keenan via RT <perlbug-followup@​perl.org> [2012-08-21 03​:55]​:

I don't think it's particularly inconsistent.

It is completely inconsistent with the way slices work in every other
case I can think of, and very surprising. This is a bug that should be
fixed. It has the distinct smell of an implementation accident.

It is no accident. From perldata​:

  A slice of an empty list is still an empty list. Thus​:

  @​a = ()[1,0]; # @​a has no elements
  @​b = (@​a)[0,1]; # @​b has no elements
  @​c = (0,1)[2,3]; # @​c has no elements

  But​:

  @​a = (1)[1,0]; # @​a has two elements
  @​b = (1,undef)[1,0,2]; # @​b has three elements

  This makes it easy to write loops that terminate when a null list is
  returned​:

  while ( ($home, $user) = (getpwent)[7,0]) {
  printf "%-8s %s\n", $user, $home;
  }

--
Rick Delaney
rick@​bort.ca

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2012

@cpansprout - Status changed from 'open' to 'rejected'

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2012

From @ap

* Rick Delaney <rick@​bort.ca> [2012-08-31 06​:10]​:

On Aug 31 2012, Aristotle Pagaltzis wrote​:

* James E Keenan via RT <perlbug-followup@​perl.org> [2012-08-21 03​:55]​:

I don't think it's particularly inconsistent.

It is completely inconsistent with the way slices work in every other
case I can think of, and very surprising. This is a bug that should be
fixed. It has the distinct smell of an implementation accident.

It is no accident. From perldata​:

I do not think your quotation says about this what you think it says.

   A slice of an empty list is still an empty list\.  Thus&#8203;:

       @&#8203;a = \(\)\[1\,0\];           \# @&#8203;a has no elements
       @&#8203;b = \(@&#8203;a\)\[0\,1\];         \# @&#8203;b has no elements
       @&#8203;c = \(0\,1\)\[2\,3\];        \# @&#8203;c has no elements

   But&#8203;:

       @&#8203;a = \(1\)\[1\,0\];          \# @&#8203;a has two elements
       @&#8203;b = \(1\,undef\)\[1\,0\,2\];  \# @&#8203;b has three elements

The bug report was about the surprising difference between these​:

  @​x = ( (2)[0,1,2] );
  @​y = ( (2)[ 1,2] );

In both cases the slice is of a one-element list, not of an empty list,
so the “But” clause from the quoted documentation applies and neither
array should be empty.

Regards,
--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2012

From @ikegami

On Fri, Aug 31, 2012 at 12​:51 AM, Aristotle Pagaltzis <pagaltzis@​gmx.de>wrote​:

* Rick Delaney <rick@​bort.ca> [2012-08-31 06​:10]​:

On Aug 31 2012, Aristotle Pagaltzis wrote​:

* James E Keenan via RT <perlbug-followup@​perl.org> [2012-08-21
03​:55]​:

I don't think it's particularly inconsistent.

It is completely inconsistent with the way slices work in every other
case I can think of, and very surprising. This is a bug that should be
fixed. It has the distinct smell of an implementation accident.

It is no accident. From perldata​:

I do not think your quotation says about this what you think it says.

   A slice of an empty list is still an empty list\.  Thus&#8203;:

       @&#8203;a = \(\)\[1\,0\];           \# @&#8203;a has no elements
       @&#8203;b = \(@&#8203;a\)\[0\,1\];         \# @&#8203;b has no elements
       @&#8203;c = \(0\,1\)\[2\,3\];        \# @&#8203;c has no elements

   But&#8203;:

       @&#8203;a = \(1\)\[1\,0\];          \# @&#8203;a has two elements
       @&#8203;b = \(1\,undef\)\[1\,0\,2\];  \# @&#8203;b has three elements

The bug report was about the surprising difference between these​:

@&#8203;x = \( \(2\)\[0\,1\,2\] \);
@&#8203;y = \( \(2\)\[  1\,2\] \);

In both cases the slice is of a one-element list, not of an empty list,
so the “But” clause from the quoted documentation applies and neither
array should be empty.

Actually, it is covered​:

@​c = (0,1)[2,3]; # @​c has no elements

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2012

From @perhunter

On 08/31/2012 12​:51 AM, Aristotle Pagaltzis wrote​:

* Rick Delaney <rick@​bort.ca> [2012-08-31 06​:10]​:

On Aug 31 2012, Aristotle Pagaltzis wrote​:

* James E Keenan via RT <perlbug-followup@​perl.org> [2012-08-21 03​:55]​:

I don't think it's particularly inconsistent.

It is completely inconsistent with the way slices work in every other
case I can think of, and very surprising. This is a bug that should be
fixed. It has the distinct smell of an implementation accident.

It is no accident. From perldata​:

I do not think your quotation says about this what you think it says.

    A slice of an empty list is still an empty list\.  Thus&#8203;:

        @&#8203;a = \(\)\[1\,0\];           \# @&#8203;a has no elements
        @&#8203;b = \(@&#8203;a\)\[0\,1\];         \# @&#8203;b has no elements
        @&#8203;c = \(0\,1\)\[2\,3\];        \# @&#8203;c has no elements

    But&#8203;:

        @&#8203;a = \(1\)\[1\,0\];          \# @&#8203;a has two elements
        @&#8203;b = \(1\,undef\)\[1\,0\,2\];  \# @&#8203;b has three elements

The bug report was about the surprising difference between these​:

 @&#8203;x = \( \(2\)\[0\,1\,2\] \);
 @&#8203;y = \( \(2\)\[  1\,2\] \);

In both cases the slice is of a one-element list, not of an empty list,
so the “But” clause from the quoted documentation applies and neither
array should be empty.

look at the @​c example which is the same as your @​y line. slicing only
above the last element is an empty list. if any value from the slice is
from an existing element, the whole slice has elements. been that way
forever from what i know to support that an empty list (even assigned to
a list of scalars) is false. i was thinking about this feature to add to
this thread but couldn't find the doc quote for it.

my view is the docs could use a little more clarity saying that a slice
of only indexes beyond the last one is always an empty list.

uri

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2012

From Eirik-Berg.Hanssen@allverden.no

On Fri, Aug 31, 2012 at 7​:20 AM, Uri Guttman <uri@​stemsystems.com> wrote​:

my view is the docs could use a little more clarity saying that a slice of
only indexes beyond the last one is always an empty list.

  ... or just explain why C<< (0,1)[2,3] >> is an example of "a slice of an
empty list". To me it looks like a slice of C<< (0, 1) >>, which in turn
does not look particularly empty ...

Eirik

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2012

From @ap

* Eric Brine <ikegami@​adaelis.com> [2012-08-31 07​:15]​:

On Fri, Aug 31, 2012 at 12​:51 AM, Aristotle Pagaltzis <pagaltzis@​gmx.de>wrote​:

In both cases the slice is of a one-element list, not of an empty
list, so the “But” clause from the quoted documentation applies and
neither array should be empty.

Actually, it is covered​:

@​c = (0,1)[2,3]; # @​c has no elements

D’oh. That is not a particularly empty list, the introductory verbiage
is misleading. So that means​:

  @​a = 1..2;
  @​b = @​a [4,5,6]; # @​b has 3 elements (all undef)
  @​c = (@​a)[4,5,6]; # @​c has 0 elements

It is an understatement to say I’m not wild about this design, but if
it is intended…

Patch attached.

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2012

From @ap

fix-perldata-empty-list-slice.diff
diff --git i/pod/perldata.pod w/pod/perldata.pod
index 3a4776c..9bff98f 100644
--- i/pod/perldata.pod
+++ w/pod/perldata.pod
@@ -777,13 +777,18 @@ A slice of an empty list is still an empty list.  Thus:
 
     @a = ()[1,0];           # @a has no elements
     @b = (@a)[0,1];         # @b has no elements
-    @c = (0,1)[2,3];        # @c has no elements
 
 But:
 
     @a = (1)[1,0];          # @a has two elements
     @b = (1,undef)[1,0,2];  # @b has three elements
 
+More generally, a slice yields the empty list if it indexes only
+beyond the end of a list:
+
+    @a = (1)[  1,2];        # @a has no elements
+    @b = (1)[0,1,2];        # @b has three elements
+
 This makes it easy to write loops that terminate when a null list
 is returned:
 

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2012

From jrw32982@yahoo.com

Please see the example below.

First, as the example below shows, there are inconsistencies depending on whether or not the list is held in a variable (@​a1 or @​a4) or a constant ((8) or ()) or a function return value.  I don't see how these can be anything other than one or more bugs.

Second, if there is intention (as Uri says and perldata says) to return an empty list when the list being sliced is an empty list, then there is a bug (as shown below) when the empty list is held in a variable @​a4 vs. an empty list constant or an empty list returned from a function f4.

Third, perhaps the documentation could be enhanced to make this intentional inconsistency (in the handling of list slices when the subscripts are off the end of the list and the list goes from non-empty to empty) more obvious in documentation, since it is surprising due to the inconsistency.

-- John

#!/usr/bin/perl
use warnings;
use Data​::Dumper;

sub f1 { return (9) }
@​a1 = (7);
@​x1 = (@​a1[0,1,2]);  # [ 7, undef, undef ];
@​y1 = (@​a1[  1,2]);  # [    undef, undef ];
@​x2 = ((8)[0,1,2]);  # [ 8, undef, undef ];
@​y2 = ((8)[  1,2]);  # [];
@​x3 = ((f1)[0,1,2]); # [ 9, undef, undef ];
@​y3 = ((f1)[  1,2]); # [];

sub f4 { return () }
@​a4 = ();
@​x4 = (@​a4[0,1,2]);  # [ undef, undef, undef ];
@​y4 = (@​a4[  1,2]);  # [        undef, undef ];
@​x5 = (()[0,1,2]);   # [];
@​y5 = (()[  1,2]);   # [];
@​x6 = ((f4)[0,1,2]); # [];
@​y6 = ((f4)[  1,2]); # [];

print Data​::Dumper->Dump([\@​x1, \@​y1], [qw[x1 y1]]);
print Data​::Dumper->Dump([\@​x2, \@​y2], [qw[x2 y2]]);
print Data​::Dumper->Dump([\@​x3, \@​y3], [qw[x3 y3]]);
print "\n";
print Data​::Dumper->Dump([\@​x4, \@​y4], [qw[x4 y4]]);
print Data​::Dumper->Dump([\@​x5, \@​y5], [qw[x5 y5]]);
print Data​::Dumper->Dump([\@​x6, \@​y6], [qw[x6 y6]]);

________________________________
From​: Eirik Berg Hanssen <Eirik-Berg.Hanssen@​allverden.no>
To​: Uri Guttman <uri@​stemsystems.com>
Cc​: perl5-porters@​perl.org
Sent​: Friday, August 31, 2012 1​:57 AM
Subject​: Re​: [perl #114498] List slice *sometimes* ignores undefined items

On Fri, Aug 31, 2012 at 7​:20 AM, Uri Guttman <uri@​stemsystems.com> wrote​:

my view is the docs could use a little more clarity saying that a slice of only indexes beyond the last one is always an empty list.
  ... or just explain why C<< (0,1)[2,3] >> is an example of "a slice of an empty list".  To me it looks like a slice of C<< (0, 1) >>, which in turn does not look particularly empty ...

Eirik

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2012

From jrw32982@yahoo.com

I'm not wild about it either, since it is inconsistent, but it is documented.  It certainly threw me for a loop when I encountered it in live code.

________________________________
From​: Aristotle Pagaltzis <pagaltzis@​gmx.de>
To​: perl5-porters@​perl.org
Sent​: Friday, August 31, 2012 9​:08 AM
Subject​: Re​: [perl #114498] List slice *sometimes* ignores undefined items

* Eric Brine <ikegami@​adaelis.com> [2012-08-31 07​:15]​:

On Fri, Aug 31, 2012 at 12​:51 AM, Aristotle Pagaltzis <pagaltzis@​gmx.de>wrote​:

In both cases the slice is of a one-element list, not of an empty
list, so the “But” clause from the quoted documentation applies and
neither array should be empty.

Actually, it is covered​:

@​c = (0,1)[2,3];        # @​c has no elements

D’oh. That is not a particularly empty list, the introductory verbiage
is misleading. So that means​:

    @​a = 1..2;
    @​b =  @​a [4,5,6]; # @​b has 3 elements (all undef)
    @​c = (@​a)[4,5,6]; # @​c has 0 elements

It is an understatement to say I’m not wild about this design, but if
it is intended…

Patch attached.

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2012

From @cpansprout

On Fri Aug 31 06​:40​:15 2012, jrw32982@​yahoo.com wrote​:

Please see the example below.

First, as the example below shows, there are inconsistencies depending
on whether or not the list is held in a variable (@​a1 or @​a4) or a
constant ((8) or ()) or a function return value.� I don't see how
these can be anything other than one or more bugs.

@​a[1] and (@​a)[1] are different creatures. The former is an array
slice. The main difference is that you can assign to @​a[1], but not to
(@​a)[1].

#!/usr/bin/perl
use warnings;
use Data​::Dumper;

sub f1 { return (9) }
@​a1 = (7);
@​x1 = (@​a1[0,1,2]);� # [ 7, undef, undef ];
@​y1 = (@​a1[� 1,2]);� # [��� undef, undef ];
@​x2 = ((8)[0,1,2]);� # [ 8, undef, undef ];
@​y2 = ((8)[� 1,2]);� # [];
@​x3 = ((f1)[0,1,2]); # [ 9, undef, undef ];
@​y3 = ((f1)[� 1,2]); # [];

sub f4 { return () }
@​a4 = ();
@​x4 = (@​a4[0,1,2]);� # [ undef, undef, undef ];
@​y4 = (@​a4[� 1,2]);� # [������� undef, undef ];
@​x5 = (()[0,1,2]);�� # [];
@​y5 = (()[� 1,2]);�� # [];
@​x6 = ((f4)[0,1,2]); # [];
@​y6 = ((f4)[� 1,2]); # [];

print Data​::Dumper->Dump([\@​x1, \@​y1], [qw[x1 y1]]);
print Data​::Dumper->Dump([\@​x2, \@​y2], [qw[x2 y2]]);
print Data​::Dumper->Dump([\@​x3, \@​y3], [qw[x3 y3]]);
print "\n";
print Data​::Dumper->Dump([\@​x4, \@​y4], [qw[x4 y4]]);
print Data​::Dumper->Dump([\@​x5, \@​y5], [qw[x5 y5]]);
print Data​::Dumper->Dump([\@​x6, \@​y6], [qw[x6 y6]]);

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2012

From @cpansprout

On Fri Aug 31 06​:09​:29 2012, aristotle wrote​:

* Eric Brine <ikegami@​adaelis.com> [2012-08-31 07​:15]​:

On Fri, Aug 31, 2012 at 12​:51 AM, Aristotle Pagaltzis
<pagaltzis@​gmx.de>wrote​:

In both cases the slice is of a one-element list, not of an empty
list, so the “But” clause from the quoted documentation applies
and
neither array should be empty.

Actually, it is covered​:

@​c = (0,1)[2,3]; # @​c has no elements

D’oh. That is not a particularly empty list, the introductory verbiage
is misleading. So that means​:

@&#8203;a = 1\.\.2;
@&#8203;b =  @&#8203;a \[4\,5\,6\]; \# @&#8203;b has 3 elements \(all undef\)
@&#8203;c = \(@&#8203;a\)\[4\,5\,6\]; \# @&#8203;c has 0 elements

It is an understatement to say I’m not wild about this design, but if
it is intended…

Thank you. Applied as f51152e.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2012

From jrw32982@yahoo.com

_______________________________

From​: Father Chrysostomos via RT <perlbug-followup@​perl.org>
To​: jrw32982@​yahoo.com
Sent​: Friday, August 31, 2012 11​:47 AM
Subject​: [perl #114498] List slice *sometimes* ignores undefined items

On Fri Aug 31 06​:40​:15 2012, jrw32982@​yahoo.com wrote​:

Please see the example below.

First, as the example below shows, there are inconsistencies depending
    on whether or not the list is held in a variable (@​a1 or @​a4) or a
    constant ((8) or ()) or a function return value.  I don't see how
    these can be anything other than one or more bugs.

@​a[1] and (@​a)[1] are different creatures.  The former is an array
slice.  The main difference is that you can assign to @​a[1], but not to
(@​a)[1].

OK.  But I don't see what that has to do with this bug report.  I don't believe I ever used code like that in my submission.  I used (@​a[1]).  But regardless, if I leave off the surrounding parens, I get the same result.

Have we agreed that we have a unambiguous bug?

Here is the revised test program that still shows the bug.

#!/usr/bin/perl
use warnings;
use Data​::Dumper;

sub f1 { return (9) }
@​a1 = (7);
@​x1 = @​a1[0,1,2];  # [ 7, undef, undef ];
@​y1 = @​a1[  1,2];  # [    undef, undef ];
@​x2 = (8)[0,1,2];  # [ 8, undef, undef ];
@​y2 = (8)[  1,2];  # [];
@​x3 = (f1)[0,1,2]; # [ 9, undef, undef ];
@​y3 = (f1)[  1,2]; # [];

sub f4 { return () }
@​a4 = ();
@​x4 = @​a4[0,1,2];  # [ undef, undef, undef ];
@​y4 = @​a4[  1,2];  # [        undef, undef ];
@​x5 = ()[0,1,2];   # [];
@​y5 = ()[  1,2];   # [];
@​x6 = (f4)[0,1,2]; # [];
@​y6 = (f4)[  1,2]; # [];

print Data​::Dumper->Dump([\@​x1, \@​y1], [qw[x1 y1]]);
print Data​::Dumper->Dump([\@​x2, \@​y2], [qw[x2 y2]]);
print Data​::Dumper->Dump([\@​x3, \@​y3], [qw[x3 y3]]);
print "\n";
print Data​::Dumper->Dump([\@​x4, \@​y4], [qw[x4 y4]]);
print Data​::Dumper->Dump([\@​x5, \@​y5], [qw[x5 y5]]);
print Data​::Dumper->Dump([\@​x6, \@​y6], [qw[x6 y6]]);

@p5pRT
Copy link
Author

p5pRT commented Sep 1, 2012

From @jkeenan

On Fri Aug 31 08​:49​:00 2012, sprout wrote​:

Thank you. Applied as f51152e.

Father C​: I see this ticket in the Rejected queue. Should it actually
be in Resolved? Or is it still Open?

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

p5pRT commented Sep 2, 2012

From @cpansprout

On Fri Aug 31 09​:14​:20 2012, jrw32982@​yahoo.com wrote​:

_______________________________

From​: Father Chrysostomos via RT <perlbug-followup@​perl.org>
To​: jrw32982@​yahoo.com
Sent​: Friday, August 31, 2012 11​:47 AM
Subject​: [perl #114498] List slice *sometimes* ignores undefined
items

On Fri Aug 31 06​:40​:15 2012, jrw32982@​yahoo.com wrote​:

Please see the example below.

First, as the example below shows, there are inconsistencies
depending
� � on whether or not the list is held in a variable (@​a1 or @​a4) or
a
� � constant ((8) or ()) or a function return value.� I don't see
how
� � these can be anything other than one or more bugs.

@​a[1] and (@​a)[1] are different creatures.� The former is an array
slice.� The main difference is that you can assign to @​a[1], but not
to
(@​a)[1].

OK.� But I don't see what that has to do with this bug report.� I
don't believe I ever used code like that in my submission.� I used
(@​a[1]).

Which is an array slice, not a list silce.

But regardless, if I leave off the surrounding parens, I
get the same result.

If you add parentheses, and use (@​a)[1], you will get consistent results.

Have we agreed that we have a unambiguous bug?

No. The example below uses both array slice and list slice. If you use
only list slice, you will get consistent results. The special case
applies only to list slices.

Here is the revised test program that still shows the bug.

#!/usr/bin/perl
use warnings;
use Data​::Dumper;

sub f1 { return (9) }
@​a1 = (7);
@​x1 = @​a1[0,1,2];� # [ 7, undef, undef ];
@​y1 = @​a1[� 1,2];� # [��� undef, undef ];
@​x2 = (8)[0,1,2];� # [ 8, undef, undef ];
@​y2 = (8)[� 1,2];� # [];
@​x3 = (f1)[0,1,2]; # [ 9, undef, undef ];
@​y3 = (f1)[� 1,2]; # [];

sub f4 { return () }
@​a4 = ();
@​x4 = @​a4[0,1,2];� # [ undef, undef, undef ];
@​y4 = @​a4[� 1,2];� # [������� undef, undef ];
@​x5 = ()[0,1,2];�� # [];
@​y5 = ()[� 1,2];�� # [];
@​x6 = (f4)[0,1,2]; # [];
@​y6 = (f4)[� 1,2]; # [];

print Data​::Dumper->Dump([\@​x1, \@​y1], [qw[x1 y1]]);
print Data​::Dumper->Dump([\@​x2, \@​y2], [qw[x2 y2]]);
print Data​::Dumper->Dump([\@​x3, \@​y3], [qw[x3 y3]]);
print "\n";
print Data​::Dumper->Dump([\@​x4, \@​y4], [qw[x4 y4]]);
print Data​::Dumper->Dump([\@​x5, \@​y5], [qw[x5 y5]]);
print Data​::Dumper->Dump([\@​x6, \@​y6], [qw[x6 y6]]);

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Sep 2, 2012

From @cpansprout

On Sat Sep 01 16​:02​:23 2012, jkeenan wrote​:

On Fri Aug 31 08​:49​:00 2012, sprout wrote​:

Thank you. Applied as f51152e.

Father C​: I see this ticket in the Rejected queue. Should it actually
be in Resolved? Or is it still Open?

Well, the original bug report was not a bug. But some of the
documentation cited to support such designation was unclear, and got
clarified as a result. So I don’t really know whether it should be
rejected or resolved.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Sep 2, 2012

From jrw32982@gmail.com

Somehow, I'm not explaining this properly. This is not just a doc
bug. This is an implementation bug.

The bug is the inconsistency of the behavior of list and array slices
in the presence of out-of-bounds indexes. How is anyone supposed to
understand and predict the results achieved when an array or list
slice contains indexes off the end of the array or list? If you slice
a list, you get completely different results depending on if the slice
includes at least one in-bounds index or not. If you use an array,
you get the same results as one of the list cases, but the results do
*not* vary depending on if the slice includes at least one in-bounds
index or not. What a mess!

The only excuse for keeping the status quo would be backwards
compatibility. If that is the reason for not fixing this bug, then
please state so, and I'll go quietly. Otherwise, I submit that the
results I get from my test program below are a disaster from the point
of view of someone trying to comprehend or predict them. IMO, this is
worse than an interpreter crash, which at least indicates that
something went very wrong.

It has taken me many tries before I came up with the simplest
characterization of the results (in my bug description above). As you
can see, it is none too simple. How is someone who has not spent
hours writing and refining a test program (below) and analyzing the
results supposed to find any consistency in the results of list or
array slices when dealing with out-of-bounds indexes?

I have added to my test cases below to show this issue with all the
variations I can think of, including the difference between arrays and
lists, the difference between empty and non-empty arrays/lists, and
the difference between slices which include in-bounds indexes and
those which don't. This reminds me of the smartmatch discussion,
where nobody can predict what will happen in the general case, without
referring to a complicated table of results.

P.S. I don't think it's helping that either my reader or your reader
is screwing up the formatting of my test program which, when displayed
in a monospaced font, makes the test results clearer. I'm switching
to a gmail account rather than a yahoo account in the hopes that we
can resolve the formatting issue. I've configured my client to send
plain text, but still the emails I'm getting back from you contain
some indecipherable characters even though all I'm sending is (I
believe) ASCII. Is there something that I'm missing here? Should I
not be sending plain text emails, but instead be sending rich text
emails with the program formatted in courier?

use strict;
use warnings;
use Data​::Dumper;

sub f1 { return (9) }
my @​a1 = (7);

my @​x1 = @​a1[2,0,1]; # [ undef, 7, undef ]
my @​y1 = @​a1[2, 1]; # [ undef, undef ]
my @​x2 = (@​a1)[2,0,1]; # [ undef, 7, undef ]
my @​y2 = (@​a1)[2, 1]; # []
my @​x3 = (8)[2,0,1]; # [ undef, 8, undef ]
my @​y3 = (8)[2, 1]; # []
my @​x4 = (f1)[2,0,1]; # [ undef, 9, undef ]
my @​y4 = (f1)[2, 1]; # []

sub f5 { return () }
my @​a5 = ();

my @​x5 = @​a5[2,0,1]; # [ undef, undef, undef ]
my @​y5 = @​a5[2, 1]; # [ undef, undef ]
my @​x6 = (@​a5)[2,0,1]; # []
my @​y6 = (@​a5)[2, 1]; # []
my @​x7 = ()[2,0,1]; # []
my @​y7 = ()[2, 1]; # []
my @​x8 = (f5)[2,0,1]; # []
my @​y8 = (f5)[2, 1]; # []

print Data​::Dumper->Dump([\@​x1, \@​y1], [qw[x1 y1]]);
print Data​::Dumper->Dump([\@​x2, \@​y2], [qw[x2 y2]]);
print Data​::Dumper->Dump([\@​x3, \@​y3], [qw[x3 y3]]);
print Data​::Dumper->Dump([\@​x4, \@​y4], [qw[x4 y4]]);
print "\n";
print Data​::Dumper->Dump([\@​x5, \@​y5], [qw[x5 y5]]);
print Data​::Dumper->Dump([\@​x6, \@​y6], [qw[x6 y6]]);
print Data​::Dumper->Dump([\@​x7, \@​y7], [qw[x7 y7]]);
print Data​::Dumper->Dump([\@​x8, \@​y8], [qw[x8 y8]]);

On Sat, Sep 1, 2012 at 9​:14 PM, John Wiersba <jrw32982@​yahoo.com> wrote​:

________________________________
From​: Father Chrysostomos via RT <perlbug-followup@​perl.org>
To​: jrw32982@​yahoo.com
Sent​: Saturday, September 1, 2012 8​:18 PM
Subject​: [perl #114498] List slice *sometimes* ignores undefined items

On Fri Aug 31 09​:14​:20 2012, jrw32982@​yahoo.com wrote​:

_______________________________

From​: Father Chrysostomos via RT <perlbug-followup@​perl.org>
To​: jrw32982@​yahoo.com
Sent​: Friday, August 31, 2012 11​:47 AM
Subject​: [perl #114498] List slice *sometimes* ignores undefined
items

On Fri Aug 31 06​:40​:15 2012, jrw32982@​yahoo.com wrote​:

Please see the example below.

First, as the example below shows, there are inconsistencies
depending
� � on whether or not the list is held in a variable (@​a1 or @​a4) or
a
� � constant ((8) or ()) or a function return value.� I don't see
how
� � these can be anything other than one or more bugs.

@​a[1] and (@​a)[1] are different creatures.� The former is an array
slice.� The main difference is that you can assign to @​a[1], but not
to
(@​a)[1].

OK.� But I don't see what that has to do with this bug report.� I
don't believe I ever used code like that in my submission.� I used
(@​a[1]).

Which is an array slice, not a list silce.

But regardless, if I leave off the surrounding parens, I
get the same result.

If you add parentheses, and use (@​a)[1], you will get consistent results.

Have we agreed that we have a unambiguous bug?

No. The example below uses both array slice and list slice. If you use
only list slice, you will get consistent results. The special case
applies only to list slices.

Here is the revised test program that still shows the bug.

#!/usr/bin/perl
use warnings;
use Data​::Dumper;

sub f1 { return (9) }
@​a1 = (7);
@​x1 = @​a1[0,1,2];� # [ 7, undef, undef ];
@​y1 = @​a1[� 1,2];� # [��� undef, undef ];
@​x2 = (8)[0,1,2];� # [ 8, undef, undef ];
@​y2 = (8)[� 1,2];� # [];
@​x3 = (f1)[0,1,2]; # [ 9, undef, undef ];
@​y3 = (f1)[� 1,2]; # [];

sub f4 { return () }
@​a4 = ();
@​x4 = @​a4[0,1,2];� # [ undef, undef, undef ];
@​y4 = @​a4[� 1,2];� # [������� undef, undef ];
@​x5 = ()[0,1,2];�� # [];
@​y5 = ()[� 1,2];�� # [];
@​x6 = (f4)[0,1,2]; # [];
@​y6 = (f4)[� 1,2]; # [];

print Data​::Dumper->Dump([\@​x1, \@​y1], [qw[x1 y1]]);
print Data​::Dumper->Dump([\@​x2, \@​y2], [qw[x2 y2]]);
print Data​::Dumper->Dump([\@​x3, \@​y3], [qw[x3 y3]]);
print "\n";
print Data​::Dumper->Dump([\@​x4, \@​y4], [qw[x4 y4]]);
print Data​::Dumper->Dump([\@​x5, \@​y5], [qw[x5 y5]]);
print Data​::Dumper->Dump([\@​x6, \@​y6], [qw[x6 y6]]);

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Sep 2, 2012

From @ap

* John Wiersba <jrw32982@​gmail.com> [2012-09-02 07​:45]​:

Somehow, I'm not explaining this properly.

Don’t worry, you made yourself understood.

This is not just a doc bug. This is an implementation bug.

No. It is a dubious design, maybe a design bug. It *is* surprising and
messy. But the *implementation* is not buggy – it implements the messy
design correctly.

This reminds me of the smartmatch discussion, where nobody can predict
what will happen in the general case, without referring to
a complicated table of results.

But actually, this is very different​: *once you know*, it is very easy
to say which of your test cases will produce which result under what
circumstances.

It is extremely surprising however, if you do not know.

The lack of parallelism between arrays and lists makes me very unhappy.

But if it was designed this way and documented as it is for such a long
time, then I rather doubt it can change. I don’t know how much code
relies on it (I have probably never written any – if anything, changing
this is liable to fix code that I have written), but this cannot even be
searched for on grep.cpan.me or such to see how disruptive it might be
to change it. So if it were to be changed there would have to be an
extremely long lead time with a (runtime :-( ) deprecation warning.

P.S. […]

I don’t think anyone is missing any point because of formatting. Your
mails exceed ASCII by including non-breaking spaces (U+00A0), but that
is in Latin-1 – no Unicode needed. And your mails have all the requisite
headers for that to work correctly. It is FC’s mail client that isn’t up
to snuff.

Regards,
--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

@p5pRT
Copy link
Author

p5pRT commented Sep 2, 2012

From @cpansprout

On Sun Sep 02 05​:51​:27 2012, aristotle wrote​:

It is FC’s mail client that isn’t up
to snuff.

I am using the RT web interface. I think I know what is going on now.
It treats Latin-1 as UTF-8, instead of converting it.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Sep 2, 2012

From jrw32982@yahoo.com

________________________________
From​: Aristotle Pagaltzis <pagaltzis@​gmx.de>
To​: perl5-porters@​perl.org
Sent​: Sunday, September 2, 2012 8​:50 AM
Subject​: Re​: [perl #114498] List slice *sometimes* ignores undefined items

* John Wiersba <jrw32982@​gmail.com> [2012-09-02 07​:45]​:

Somehow, I'm not explaining this properly.

Don’t worry, you made yourself understood.

This is not just a doc bug. This is an implementation bug.

No. It is a dubious design, maybe a design bug. It *is* surprising and
messy. But the *implementation* is not buggy – it implements the messy
design correctly.

OK, I see that's one way of looking at it.  However my way of looking at it is that there's an implementation bug which has been documented (but maybe not documented well enough?).  There is a limit at which we should consider something an implementation bug rather than just some quirk to be documented.  For example, if "print 7" prints "q" and it's documented as such, it's still a bug that should be fixed.  But I do agree with your point below that if there's a lot (where "lot" needs to be defined) of code which depends on the bug, then maybe it shouldn't be fixed.

This reminds me of the smartmatch discussion, where nobody can predict

what will happen in the general case, without referring to
a complicated table of results.

But actually, this is very different​: *once you know*, it is very easy
to say which of your test cases will produce which result under what
circumstances.

It is extremely surprising however, if you do not know.

The lack of parallelism between arrays and lists makes me very unhappy.

The rule took me a long time to figure out (or even to figure out that there was a rule).  From my initial investigation, which I originally coded, I thought the rule was​:  a slice returns undef for each specified index which is off the end of the array or list.  Big mistake!  That only works if 1) it's an array slice rather than a list slice, or 2) if the list slice has at least one index not out-of-bounds.

The actual complete rule seems to be​:

  1. An array slice always returns one item for each index specified, returning undef for each out-of-bounds index.
  2. Like an array slice, a list slice which contains at least one index which is not out-of-bounds returns one item for each index specified, returning undef for each out-of-bounds index.
  3. However, unlike an array slice, a list slice where every specified index is out-of bounds returns an empty list.
I don't think the current docs make it clear that array slices are different than list slices.  That could be fixed with the above verbiage.

But the real problem is that this situation doesn't come up often enough in real life to remember.  I don't mind remembering little edge cases if they come up often and they provide value.  But when they come up infrequently they are effectively bugs because programmers will not remember them and will assume that there is no inconsistent edge case.  That's what I encountered in my production code (and I have been writing perl for 15 years, so I am not a newbie).  BTW, this is part of what people don't like about perl​:  that it has *too many* inconsistent edge cases and magic idioms.

But if it was designed this way and documented as it is for such a long

time, then I rather doubt it can change. I don’t know how much code
relies on it (I have probably never written any – if anything, changing
this is
liable to fix code that I have written), but this cannot even be
searched for on grep.cpan.me or such to see how disruptive it might be
to change it. So if it were to be changed there would have to be an
extremely long lead time with a (runtime :-( ) deprecation warning.

Well, better late than never.  :-)

P.S. […]

I don’t think anyone is missing any point because of formatting. Your
mails exceed ASCII by including non-breaking spaces (U+00A0), but that
is in Latin-1 – no Unicode needed. And your mails have all the requisite
headers for that to work correctly. It is FC’s mail client that isn’t up
to snuff.

It must be that U+00A0 is added when there are 2+ consecutive spaces.  I added extra spaces to make the code line up if viewed in a monospace font.

-- John

@p5pRT
Copy link
Author

p5pRT commented Sep 2, 2012

From @cpansprout

On Sun Sep 02 13​:34​:41 2012, jrw32982@​yahoo.com wrote​:

________________________________
From​: Aristotle Pagaltzis <pagaltzis@​gmx.de>
To​: perl5-porters@​perl.org
Sent​: Sunday, September 2, 2012 8​:50 AM
Subject​: Re​: [perl #114498] List slice *sometimes* ignores undefined
items

* John Wiersba <jrw32982@​gmail.com> [2012-09-02 07​:45]​:

Somehow, I'm not explaining this properly.

Don’t worry, you made yourself understood.

This is not just a doc bug. This is an implementation bug.

No. It is a dubious design, maybe a design bug. It *is* surprising
and
messy. But the *implementation* is not buggy – it implements the
messy
design correctly.

OK, I see that's one way of looking at it.  However my way of looking
at it is that there's an implementation bug which has been
documented (but maybe not documented well enough?).  There is a
limit at which we should consider something an implementation bug
rather than just some quirk to be documented.  For example, if
"print 7" prints "q" and it's documented as such, it's still a bug
that should be fixed.  But I do agree with your point below that if
there's a lot (where "lot" needs to be defined) of code which
depends on the bug, then maybe it shouldn't be fixed.

This reminds me of the smartmatch discussion, where nobody can
predict

what will happen in the general case, without referring to
a complicated table of results.

But actually, this is very different​: *once you know*, it is very
easy
to say which of your test cases will produce which result under what
circumstances.

It is extremely surprising however, if you do not know.

The lack of parallelism between arrays and lists makes me very
unhappy.

The rule took me a long time to figure out (or even to figure out that
there was a rule).  From my initial investigation, which I
originally coded, I thought the rule was​:  a slice returns undef
for each specified index which is off the end of the array or list.
Big mistake!  That only works if 1) it's an array slice rather than
a list slice, or 2) if the list slice has at least one index not
out-of-bounds.

The actual complete rule seems to be​:

1\. An array slice always returns one item for each index specified\,

returning undef for each out-of-bounds index.
2. Like an array slice, a list slice which contains at least one
index which is not out-of-bounds returns one item for each index
specified, returning undef for each out-of-bounds index.
3. However, unlike an array slice, a list slice where every specified
index is out-of bounds returns an empty list.
I don't think the current docs make it clear that array slices are
different than list slices.  That could be fixed with the above
verbiage.

But the real problem is that this situation doesn't come up often
enough in real life to remember.  I don't mind remembering little
edge cases if they come up often and they provide value.  But when
they come up infrequently they are effectively bugs because
programmers will not remember them and will assume that there is no
inconsistent edge case.  That's what I encountered in my production
code (and I have been writing perl for 15 years, so I am not a
newbie).  BTW, this is part of what people don't like about perl​:
that it has *too many* inconsistent edge cases and magic idioms.

But if it was designed this way and documented as it is for such a
long

time, then I rather doubt it can change. I don’t know how much code
relies on it (I have probably never written any – if anything,
changing
this is
liable to fix code that I have written), but this cannot even be
searched for on grep.cpan.me or such to see how disruptive it might
be
to change it. So if it were to be changed there would have to be an
extremely long lead time with a (runtime :-( ) deprecation warning.

Well, better late than never.  :-)

The change to the current behaviour was made in commit c73bf8e.
The note in perl56delta.pod was added in commit 08cd895, along with
the documentation in perldata.pod. What strikes me is that perl56delta
says this​:

+=item Treatment of list slices of undef has changed
+
+When taking a slice of a literal list (as opposed to a slice of
+an array or hash), Perl used to return an empty list if the
+result happened to be composed of all undef values.
+
+The new behavior is to produce an empty list if (and only if)
+the original list was empty.

So it seems the new behaviour was not actually implemented as intended.
The documentation in perldata added by the same commit said this
originally​:

-As a special rule, if a list slice would produce a list consisting
-entirely of undefined values, the null list is produced instead.
+A slice of an empty list is still an empty list. Thus​:
+
+ @​a = ()[1,0]; # @​a has no elements
+ @​b = (@​a)[0,1]; # @​b has no elements
+ @​b = (1,undef)[1,0,1]; # @​b has three elements

Four months later, in commit 56d7751, the documentation was corrected
to match the implementation​:

A slice of an empty list is still an empty list. Thus​:

  @​a = ()[1,0]; # @​a has no elements
  @​b = (@​a)[0,1]; # @​b has no elements
- @​b = (1,undef)[1,0,1]; # @​b has three elements
+ @​c = (0,1)[2,3]; # @​c has no elements
+
+But​:
+
+ @​a = (1)[1,0]; # @​a has two elements
+ @​b = (1,undef)[1,0,2]; # @​b has three elements

So maybe this should change to what is documented in perl56delta.pod.
In any case, this is not resolved, so I’m reopening it.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Sep 2, 2012

@cpansprout - Status changed from 'rejected' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Sep 3, 2012

From jrw32982@yahoo.com

________________________________
From​: Father Chrysostomos via RT <perlbug-followup@​perl.org>
To​:
Cc​: perl5-porters@​perl.org
Sent​: Sunday, September 2, 2012 7​:18 PM
Subject​: [perl #114498] List slice *sometimes* ignores undefined items

On Sun Sep 02 13​:34​:41 2012, jrw32982@​yahoo.com wrote​:

...
The actual complete rule seems to be​:

    1. An array slice always returns one item for each index specified,
    returning undef for each out-of-bounds index.
    2. Like an array slice, a list slice which contains at least one
    index which is not out-of-bounds returns one item for each index
    specified, returning undef for each out-of-bounds index.
    3. However, unlike an array slice, a list slice where every specified
    index is out-of bounds returns an empty list.
I don't think the current docs make it clear that array slices are
    different than list slices.  That could be fixed with the above
    verbiage.
...

The change to the current behaviour was made in commit c73bf8e.
The note in perl56delta.pod was added in commit 08cd895, along with
the documentation in perldata.pod.  What strikes me is that perl56delta
says this​:

+=item Treatment of list slices of undef has changed
+
+When taking a slice of a literal list (as opposed to a slice of
+an array or hash), Perl used to return an empty list if the
+result happened to be composed of all undef values.
+
+The new behavior is to produce an empty list if (and only if)
+the original list was empty.

So it seems the new behaviour was not actually implemented as intended.
The documentation in perldata added by the same commit said this
originally​:

-As a special rule, if a list slice would produce a list consisting
-entirely of undefined values, the null list is produced instead.
+A slice of an empty list is still an empty list.  Thus​:
+
+    @​a = ()[1,0];          # @​a has no elements
+    @​b = (@​a)[0,1];        # @​b has no elements
+    @​b = (1,undef)[1,0,1];  # @​b has three elements

Four months later, in commit 56d7751, the documentation was corrected
to match the implementation​:

A slice of an empty list is still an empty list.  Thus​:

    @​a = ()[1,0];          # @​a has no elements
    @​b = (@​a)[0,1];        # @​b has no elements
-    @​b = (1,undef)[1,0,1];  # @​b has three elements
+    @​c = (0,1)[2,3];        # @​c has no elements
+
+But​:
+
+    @​a = (1)[1,0];          # @​a has two elements
+    @​b = (1,undef)[1,0,2];  # @​b has three elements

So maybe this should change to what is documented in perl56delta.pod.
In any case, this is not resolved, so I’m reopening it.

--

Father Chrysostomos

---
via perlbug​:  queue​: perl5 status​: rejected
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=114498

FC​: thanks for checking into this.  I was a little scared that I'd missed a case after I read the comments that you unearthed (above).  But after running a new test script against perl 5.8.9 and 5.14.2,  the results still seem to agree with my list of rules (above).  The results apparently do *not* depend on the *value* of the specified elements (whether or not they're undefined), but only on whether or not the specified indexes are in-bounds or out-of-bounds.

-- John

@p5pRT
Copy link
Author

p5pRT commented Sep 6, 2012

From @ap

* Father Chrysostomos via RT <perlbug-followup@​perl.org> [2012-09-03 01​:20]​:

So it seems the new behaviour was not actually implemented as
intended.

Phew. I’m very glad to hear the current behaviour was not by design,
much less by Larry’s design… but is in fact an implementation bug. In
which case – yes please, let’s get rid of the Surprise! “feature”.

The documentation in perldata added by the same commit said this
originally​:

-As a special rule, if a list slice would produce a list consisting
-entirely of undefined values, the null list is produced instead.
+A slice of an empty list is still an empty list. Thus​:
+
+ @​a = ()[1,0]; # @​a has no elements
+ @​b = (@​a)[0,1]; # @​b has no elements
+ @​b = (1,undef)[1,0,1]; # @​b has three elements

That actually makes sense. There’s still an asymmetry with arrays,
in that

  @​a = ();
  @​b = @​a [0,1]; # @​b would have 2 elements
  @​c = (@​a)[0,1]; # @​c would have 0 elements

but this is far less bewildering because

  @​a = ('a'..'c');
  @​b = @​a [5,6]; # @​b would have 2 elements
  @​c = (@​a)[5,6]; # @​c would have 2 elements

and the empty-list-only exemption is in fact useful in just the way
outlined in the docs.

And this special case is much easier to explain​: “slices of empty
literal lists always yield the empty list“. Simple to understand,
and thus much easier to learn and to remember.

Let’s have it that way.

--
*AUTOLOAD=*_;sub _{s/​::([^​:]*)$/print$1,(",$\/"," ")[defined wantarray]/e;chop;$_}
&Just->another->Perl->hack;
#Aristotle Pagaltzis // <http​://plasmasturm.org/>

@p5pRT
Copy link
Author

p5pRT commented Sep 20, 2012

From @doy

On Thu, Sep 20, 2012 at 09​:02​:43AM -0700, John Wiersba wrote​:

BTW, I notice that http​://perldoc.perl.org/perlrepository.html shows
up as being in the 5.12 documentation, but not in 5.16.  Do you know
why that is?  This looks like very useful information, but it's not in
the latest perl release.

All the information in perlrepository was moved to either perlhack or
perlgit.

-doy

@p5pRT
Copy link
Author

p5pRT commented Sep 20, 2012

From @cpansprout

On Thu Sep 20 08​:07​:24 2012, jrw32982@​yahoo.com wrote​:

Yes, but never having done that before, it will take me a while to
figure it out.  Let me test your patch first.  I have found
perldoc.perl.org/perlrepository.html to help me work through the
steps.  If I have questions getting things working, should I
continue to use perlbug-followup@​perl.org to get straightened out?

Yes, that’s fine.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Sep 20, 2012

From jrw32982@yahoo.com

Thanks, Jesse.

It see the perlhack page on perldoc.perl.org, but
that site can't find any perlgit page.  I did find some links to perlgit
within perlhack page, but unfortunately they're broken.  I was able to run
"man perlgit" after building the blead source and find the perlgit man page that was built from blead.  But since I used git to
get the repository to be built, it would have been useful to have been able to
see perlgit on perldoc.perl.org before doing that.

Also, when I built perl from blead, for some reason, it didn't build perldoc.  I built perl like this​:

mkdir ~/perl ~/perl/src
git clone http​://perl5.git.perl.org/perl.git ~/perl/src
cd ~/perl/src
git branch list-slice
git checkout list-slice

Then, in order to get Configure to work with -des, I used​:

./Configure -des -Dusedevel -Dprefix=~/perl
make
make test
make install

At this point, I have ~/perl/bin filled with​:
a2p5.17.5             h2ph5.17.5        piconv5.17.5      psed5.17.5
c2ph5.17.5            h2xs5.17.5        pl2pm5.17.5       pstruct5.17.5
config_data5.17.5     instmodsh5.17.5   pod2html5.17.5    ptar5.17.5
corelist5.17.5        json_pp5.17.5     pod2latex5.17.5   ptardiff5.17.5
cpan2dist5.17.5       libnetcfg5.17.5   pod2man5.17.5     ptargrep5.17.5
cpan5.17.5            perl5.17.5        pod2text5.17.5    s2p5.17.5
cpanp-run-perl5.17.5  perlbug5.17.5     pod2usage5.17.5   shasum5.17.5
cpanp5.17.5           perldoc5.17.5     podchecker5.17.5  splain5.17.5
enc2xs5.17.5          perlivp5.17.5     podselect5.17.5   xsubpp5.17.5
find2perl5.17.5       perlthanks5.17.5  prove5.17.5       zipdetails5.17.5

but no perldoc in there.  Is that because I built the development release? 

One further question​: in order to test Father's patch, should I have built the development (5.17) release, or should I have built 5.16?

Thanks!
-- John

________________________________
From​: Jesse Luehrs <doy@​tozt.net>
To​: John Wiersba <jrw32982@​yahoo.com>
Cc​: "perlbug-followup@​perl.org" <perlbug-followup@​perl.org>
Sent​: Thursday, September 20, 2012 12​:05 PM
Subject​: Re​: [perl #114498] List slice *sometimes* ignores undefined items

On Thu, Sep 20, 2012 at 09​:02​:43AM -0700, John Wiersba wrote​:

BTW, I notice that http​://perldoc.perl.org/perlrepository.html shows
up as being in the 5.12 documentation, but not in 5.16.  Do you know
why that is?  This looks like very useful information, but it's not in
the latest perl release.

All the information in perlrepository was moved to either perlhack or
perlgit.

-doy

@p5pRT
Copy link
Author

p5pRT commented Oct 13, 2012

From @cpansprout

Sorry you got no response. I missed this message.

On Thu Sep 20 09​:59​:19 2012, jrw32982@​yahoo.com wrote​:

Thanks, Jesse.

It see the perlhack page on perldoc.perl.org, but
that site can't find any perlgit page. I did find some links to
perlgit
within perlhack page, but unfortunately they're broken. I was able
to run
"man perlgit" after building the blead source and find the perlgit man
page that was built from blead. But since I used git to
get the repository to be built, it would have been useful to have been
able to
see perlgit on perldoc.perl.org before doing that.

Also, when I built perl from blead, for some reason, it didn't build
perldoc. I built perl like this​:

mkdir ~/perl ~/perl/src
git clone http​://perl5.git.perl.org/perl.git ~/perl/src
cd ~/perl/src
git branch list-slice
git checkout list-slice

Then, in order to get Configure to work with -des, I used​:

./Configure -des -Dusedevel -Dprefix=~/perl
make
make test
make install

At this point, I have ~/perl/bin filled with​:
a2p5.17.5 h2ph5.17.5 piconv5.17.5 psed5.17.5
c2ph5.17.5 h2xs5.17.5 pl2pm5.17.5
pstruct5.17.5
config_data5.17.5 instmodsh5.17.5 pod2html5.17.5 ptar5.17.5
corelist5.17.5 json_pp5.17.5 pod2latex5.17.5
ptardiff5.17.5
cpan2dist5.17.5 libnetcfg5.17.5 pod2man5.17.5
ptargrep5.17.5
cpan5.17.5 perl5.17.5 pod2text5.17.5 s2p5.17.5
cpanp-run-perl5.17.5 perlbug5.17.5 pod2usage5.17.5 shasum5.17.5
cpanp5.17.5 perldoc5.17.5 podchecker5.17.5 splain5.17.5

------------------------^^^^^^^^^^^^^

enc2xs5.17.5 perlivp5.17.5 podselect5.17.5 xsubpp5.17.5
find2perl5.17.5 perlthanks5.17.5 prove5.17.5
zipdetails5.17.5

but no perldoc in there. Is that because I built the development
release?

See my crude ASCII arrow. :-)

One further question​: in order to test Father's patch,
should I have built the development (5.17) release, or should I have
built 5.16?

The latest snapshot of the development (blead) branch is the best thing
to use. See
<http​://perl5.git.perl.org/perl.git/shortlog/refs/heads/blead>. If you
use rsync, this branch is called perl-current.

Thanks!
-- John

________________________________
From​: Jesse Luehrs <doy@​tozt.net>
To​: John Wiersba <jrw32982@​yahoo.com>
Cc​: "perlbug-followup@​perl.org" <perlbug-followup@​perl.org>
Sent​: Thursday, September 20, 2012 12​:05 PM
Subject​: Re​: [perl #114498] List slice *sometimes* ignores undefined
items

On Thu, Sep 20, 2012 at 09​:02​:43AM -0700, John Wiersba wrote​:

BTW, I notice that http​://perldoc.perl.org/perlrepository.html
shows
up as being in the 5.12 documentation, but not in 5.16. Do you
know
why that is? This looks like very useful information, but it's not
in
the latest perl release.

All the information in perlrepository was moved to either perlhack or
perlgit.

-doy

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Oct 10, 2013

From @ap

* Father Chrysostomos via RT <perlbug-followup@​perl.org> [2012-09-19 19​:00]​:

Would you be willing to write a doc patch?

Sorry it took so long to get around to this. In the 2 weeks you needed
to produce a patch, the details of the matter slipped my mind entirely,
and going back over a long thread to refamiliarise myself with something
half-remembered is dreadful work to me, so in the end I only got back to
it once I lost all recollection of the matter and could read it afresh.

How’s the attached look to you? John?

--
*AUTOLOAD=*_;sub _{s/..([^​:]*)$/()[print$1,(",$\/"," ")[defined wantarray]]/e;$_}
&Just->another->Perl->hack;
#Aristotle Pagaltzis // <http​://plasmasturm.org/>

@p5pRT
Copy link
Author

p5pRT commented Oct 10, 2013

From @ap

0001-perldata-document-corrected-list-slicing-behaviour.patch
From 385013a1eff5855e500f7f6a2657260f0673cf19 Mon Sep 17 00:00:00 2001
Message-Id: <385013a1eff5855e500f7f6a2657260f0673cf19.1381382810.git.pagaltzis@gmx.de>
From: Aristotle Pagaltzis <pagaltzis@gmx.de>
Date: Thu, 10 Oct 2013 07:24:10 +0200
Subject: [PATCH] perldata: document corrected list slicing behaviour

---
 pod/perldata.pod | 25 ++++++++++---------------
 1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/pod/perldata.pod b/pod/perldata.pod
index 254884d..7dc4cde 100644
--- a/pod/perldata.pod
+++ b/pod/perldata.pod
@@ -879,26 +879,21 @@ values of the array or hash.
         s/(\w+)/\u\L$1/g;   # "titlecase" words
     }
 
-A slice of an empty list is still an empty list.  Thus:
+As a special exception, when you slice a list (but not an array or a hash),
+if the list evaluates to empty, then taking a slice of that empty list will
+always yield the empty list in turn.  Thus:
 
-    @a = ()[1,0];           # @a has no elements
-    @b = (@a)[0,1];         # @b has no elements
-
-But:
-
-    @a = (1)[1,0];          # @a has two elements
-    @b = (1,undef)[1,0,2];  # @b has three elements
-
-More generally, a slice yields the empty list if it indexes only
-beyond the end of a list:
-
-    @a = (1)[  1,2];        # @a has no elements
-    @b = (1)[0,1,2];        # @b has three elements
+    @a = ()[0,1];          # @a has no elements
+    @b = (@a)[0,1];        # @b has no elements
+    @c = (sub{}->())[0,1]; # @c has no elements
+    @d = ('a','b')[0,1];   # @d has two elements
+    @e = (@d)[0,1,8,9];    # @e has four elements
+    @f = (@d)[8,9];        # @f has two elements
 
 This makes it easy to write loops that terminate when a null list
 is returned:
 
-    while ( ($home, $user) = (getpwent)[7,0]) {
+    while ( ($home, $user) = (getpwent)[7,0] ) {
         printf "%-8s %s\n", $user, $home;
     }
 
-- 
1.8.3.4

@p5pRT
Copy link
Author

p5pRT commented Oct 10, 2013

From jrw32982@yahoo.com

Thanks for working on this, Aristotle!

I don't think what you wrote is quite right, in that it implies that the special exception is only empty lists.  But really, the exception is not the contents of the list (whether or not it's empty), but the "quality" of the indexes (whether or not they are all in-bounds, or some of them are out-of-bounds).

$ perl -le 'print "<$_>" for ("x")[1,2]'
$ perl -le 'print "<$_>" for ("x")[0,1,2]'
<x>
<>
<>

So, this unusual behavior happens not only for empty lists, but for any list where all the indexes are out of bounds.

Here are my notes trying to explain this behavior to myself​:

   - An array (or hash) slice always returns one item for each index
     specified, returning undef for each out-of-bounds index.
   - Like an array slice, a list slice which contains at least one index
     which is not out-of-bounds returns one item for each index specified,
     returning undef for each out-of-bounds index.
   - However, unlike an array slice, a list slice where every specified
     index is out-of bounds returns an empty list.

This behavior is so weird (inconsistent, unexpected) that I don't think examples alone will do it justice.  It has to be written out in words, something similar to your explanation for empty lists, or my wording above.

________________________________
From​: Aristotle Pagaltzis via RT <perlbug-followup@​perl.org>
To​: jrw32982@​yahoo.com
Sent​: Thursday, October 10, 2013 1​:36 AM
Subject​: Re​: [perl #114498] List slice *sometimes* ignores undefined items

* Father Chrysostomos via RT <perlbug-followup@​perl.org> [2012-09-19 19​:00]​:

Would you be willing to write a doc patch?

Sorry it took so long to get around to this. In the 2 weeks you needed
to produce a patch, the details of the matter slipped my mind entirely,
and going back over a long thread to refamiliarise myself with something
half-remembered is dreadful work to me, so in the end I only got back to
it once I lost all recollection of the matter and could read it afresh.

How’s the attached look to you? John?

--
*AUTOLOAD=*_;sub _{s/..([^​:]*)$/()[print$1,(",$\/"," ")[defined wantarray]]/e;$_}
&Just->another->Perl->hack;
#Aristotle Pagaltzis // <http​://plasmasturm.org/>

From 385013a1eff5855e500f7f6a2657260f0673cf19 Mon Sep 17 00​:00​:00 2001
Message-Id​: <385013a1eff5855e500f7f6a2657260f0673cf19.1381382810.git.pagaltzis@​gmx.de>
From​: Aristotle Pagaltzis <pagaltzis@​gmx.de>
Date​: Thu, 10 Oct 2013 07​:24​:10 +0200
Subject​: [PATCH] perldata​: document corrected list slicing behaviour

---
pod/perldata.pod | 25 ++++++++++---------------
1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/pod/perldata.pod b/pod/perldata.pod
index 254884d..7dc4cde 100644
--- a/pod/perldata.pod
+++ b/pod/perldata.pod
@​@​ -879,26 +879,21 @​@​ values of the array or hash.
        s/(\w+)/\u\L$1/g;  # "titlecase" words
    }

-A slice of an empty list is still an empty list.  Thus​:
+As a special exception, when you slice a list (but not an array or a hash),
+if the list evaluates to empty, then taking a slice of that empty list will
+always yield the empty list in turn.  Thus​:

-    @​a = ()[1,0];          # @​a has no elements
-    @​b = (@​a)[0,1];        # @​b has no elements
-
-But​:
-
-    @​a = (1)[1,0];          # @​a has two elements
-    @​b = (1,undef)[1,0,2];  # @​b has three elements
-
-More generally, a slice yields the empty list if it indexes only
-beyond the end of a list​:
-
-    @​a = (1)[  1,2];        # @​a has no elements
-    @​b = (1)[0,1,2];        # @​b has three elements
+    @​a = ()[0,1];          # @​a has no elements
+    @​b = (@​a)[0,1];        # @​b has no elements
+    @​c = (sub{}->())[0,1]; # @​c has no elements
+    @​d = ('a','b')[0,1];  # @​d has two elements
+    @​e = (@​d)[0,1,8,9];    # @​e has four elements
+    @​f = (@​d)[8,9];        # @​f has two elements

This makes it easy to write loops that terminate when a null list
is returned​:

-    while ( ($home, $user) = (getpwent)[7,0]) {
+    while ( ($home, $user) = (getpwent)[7,0] ) {
        printf "%-8s %s\n", $user, $home;
    }

--
1.8.3.4

@p5pRT
Copy link
Author

p5pRT commented Oct 10, 2013

From @ap

* John Wiersba <jrw32982@​yahoo.com> [2013-10-10 19​:15]​:

I don't think what you wrote is quite right, in that it implies that
the special exception is only empty lists.  But really, the exception
is not the contents of the list (whether or not it's empty), but the
"quality" of the indexes (whether or not they are all in-bounds, or
some of them are out-of-bounds).

$ perl -le 'print "<$_>" for ("x")[1,2]'
$ perl -le 'print "<$_>" for ("x")[0,1,2]'
<x>
<>
<>

Yes, that is how it works now. I already patched the documentation to
say that.

But this doc patch is for the patch that FatherC submitted, which, as
I understand it, implements the originally intended semantics – where
slicing *only* an empty list yields an empty list.

Does it not?

Regards,
--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

@p5pRT
Copy link
Author

p5pRT commented Oct 11, 2013

From jrw32982@yahoo.com

I just tried my example below on 5.19.5 and it works the same way as I show below (the same as 5.10 - 5.18).

________________________________
From​: Aristotle Pagaltzis via RT <perlbug-followup@​perl.org>
To​: jrw32982@​yahoo.com
Sent​: Thursday, October 10, 2013 2​:19 PM
Subject​: Re​: [perl #114498] List slice *sometimes* ignores undefined items

* John Wiersba <jrw32982@​yahoo.com> [2013-10-10 19​:15]​:

I don't think what you wrote is quite right, in that it implies that
the special exception is only empty lists.  But really, the exception
is not the contents of the list (whether or not it's empty), but the
"quality" of the indexes (whether or not they are all in-bounds, or
some of them are out-of-bounds).

$ perl -le 'print "<$_>" for ("x")[1,2]'
$ perl -le 'print "<$_>" for ("x")[0,1,2]'
<x>
<>
<>

Yes, that is how it works now. I already patched the documentation to
say that.

But this doc patch is for the patch that FatherC submitted, which, as
I understand it, implements the originally intended semantics – where
slicing *only* an empty list yields an empty list.

Does it not?

Regards,
--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

@p5pRT
Copy link
Author

p5pRT commented Oct 12, 2013

From @ap

* John Wiersba <jrw32982@​yahoo.com> [2013-10-11 21​:05]​:

* Aristotle Pagaltzis <pagaltzis@​gmx.de> [2013-10-10 20​:20]​:

* John Wiersba <jrw32982@​yahoo.com> [2013-10-10 19​:15]​:

I don't think what you wrote is quite right, in that it implies
that the special exception is only empty lists.  But really, the
exception is not the contents of the list (whether or not it's
empty), but the "quality" of the indexes (whether or not they are
all in-bounds, or some of them are out-of-bounds).

$ perl -le 'print "<$_>" for ("x")[1,2]'
$ perl -le 'print "<$_>" for ("x")[0,1,2]'
<x>
<>
<>

Yes, that is how it works now. I already patched the documentation
to say that.

But this doc patch is for the patch that FatherC submitted, which,
as I understand it, implements the originally intended semantics
– where slicing *only* an empty list yields an empty list.

Does it not?

I just tried my example below on 5.19.5 and it works the same way as
I show below (the same as 5.10 - 5.18).

Yes, FC’s patch has not been applied, so any released version of perl
necessarily still works in that buggy way. We went over this already.

My question was whether you feel the phrasing I proposed conveys the
non-buggy semantics under FC’s patch clearly. Tell me something about
that please?

--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

@p5pRT
Copy link
Author

p5pRT commented Oct 12, 2013

From jrw32982@yahoo.com

Yes, I think your doc patch is clear, especially because it used the words "special exception".  It might also be helpful to include some example for contrast showing differing behavior with array and hash slices vs a list slice, since the distinction between "list" and "array" is not always clear.

________________________________
From​: Aristotle Pagaltzis via RT <perlbug-followup@​perl.org>
To​: jrw32982@​yahoo.com
Sent​: Friday, October 11, 2013 11​:11 PM
Subject​: Re​: [perl #114498] List slice *sometimes* ignores undefined items

* John Wiersba <jrw32982@​yahoo.com> [2013-10-11 21​:05]​:

* Aristotle Pagaltzis <pagaltzis@​gmx.de> [2013-10-10 20​:20]​:

* John Wiersba
<jrw32982@​yahoo.com> [2013-10-10 19​:15]​:

I don't think what you wrote is quite right, in that it implies
that the special exception is only empty lists.  But really, the
exception is not the contents of the list (whether or not it's
empty), but the "quality" of the indexes (whether or not they are
all in-bounds, or some of them are out-of-bounds).

$ perl -le 'print "<$_>" for ("x")[1,2]'
$ perl -le 'print "<$_>" for ("x")[0,1,2]'
<x>
<>
<>

Yes, that is how it works now. I already patched the documentation
to say that.

But this doc patch is
for the patch that FatherC submitted, which,
as I understand it, implements the originally intended semantics
– where slicing *only* an empty list yields an empty list.

Does it not?

I just tried my example below on 5.19.5 and it works the same way as
I show below (the same as 5.10 - 5.18).

Yes, FC’s patch has not been applied, so any released version of perl
necessarily still works in that buggy way. We went over this already.

My question was whether you feel the phrasing I proposed conveys the
non-buggy semantics under FC’s patch clearly. Tell me something about
that please?

--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

@p5pRT
Copy link
Author

p5pRT commented Mar 11, 2014

From @ap

* Aristotle Pagaltzis <pagaltzis@​gmx.de> [2013-10-10 07​:40]​:

* Father Chrysostomos via RT <perlbug-followup@​perl.org> [2012-09-19 19​:00]​:

Would you be willing to write a doc patch?

Sorry it took so long to get around to this.

Bump.

It would be nice for this to make it into 5.20.

Regards,
--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

@p5pRT
Copy link
Author

p5pRT commented May 11, 2014

From @ap

* Aristotle Pagaltzis <pagaltzis@​gmx.de> [2014-03-11 08​:20]​:

Bump.

It would be nice for this to make it into 5.20.

Maybe if I try with the patch inlined it’ll get comments quicker. :-)

@p5pRT
Copy link
Author

p5pRT commented May 11, 2014

From @ap

0001-perldata-document-corrected-list-slicing-behaviour.patch
From 385013a1eff5855e500f7f6a2657260f0673cf19 Mon Sep 17 00:00:00 2001
Message-Id: <385013a1eff5855e500f7f6a2657260f0673cf19.1381382810.git.pagaltzis@gmx.de>
From: Aristotle Pagaltzis <pagaltzis@gmx.de>
Date: Thu, 10 Oct 2013 07:24:10 +0200
Subject: [PATCH] perldata: document corrected list slicing behaviour

---
 pod/perldata.pod | 25 ++++++++++---------------
 1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/pod/perldata.pod b/pod/perldata.pod
index 254884d..7dc4cde 100644
--- a/pod/perldata.pod
+++ b/pod/perldata.pod
@@ -879,26 +879,21 @@ values of the array or hash.
         s/(\w+)/\u\L$1/g;   # "titlecase" words
     }
 
-A slice of an empty list is still an empty list.  Thus:
+As a special exception, when you slice a list (but not an array or a hash),
+if the list evaluates to empty, then taking a slice of that empty list will
+always yield the empty list in turn.  Thus:
 
-    @a = ()[1,0];           # @a has no elements
-    @b = (@a)[0,1];         # @b has no elements
-
-But:
-
-    @a = (1)[1,0];          # @a has two elements
-    @b = (1,undef)[1,0,2];  # @b has three elements
-
-More generally, a slice yields the empty list if it indexes only
-beyond the end of a list:
-
-    @a = (1)[  1,2];        # @a has no elements
-    @b = (1)[0,1,2];        # @b has three elements
+    @a = ()[0,1];          # @a has no elements
+    @b = (@a)[0,1];        # @b has no elements
+    @c = (sub{}->())[0,1]; # @c has no elements
+    @d = ('a','b')[0,1];   # @d has two elements
+    @e = (@d)[0,1,8,9];    # @e has four elements
+    @f = (@d)[8,9];        # @f has two elements
 
 This makes it easy to write loops that terminate when a null list
 is returned:
 
-    while ( ($home, $user) = (getpwent)[7,0]) {
+    while ( ($home, $user) = (getpwent)[7,0] ) {
         printf "%-8s %s\n", $user, $home;
     }
 
-- 
1.8.3.4

@p5pRT
Copy link
Author

p5pRT commented May 11, 2014

From @ap

Hi perl5-porters,

* Aristotle Pagaltzis <pagaltzis@​gmx.de> [2014-05-11 12​:15]​:

* Aristotle Pagaltzis <pagaltzis@​gmx.de> [2014-03-11 08​:20]​:

Bump.

It would be nice for this to make it into 5.20.

Maybe if I try with the patch inlined it’ll get comments quicker. :-)

Also now as a patience diff, much nicer.

@p5pRT
Copy link
Author

p5pRT commented May 11, 2014

From @ap

0001-perldata-document-corrected-list-slicing-behaviour.patch
From 385013a1eff5855e500f7f6a2657260f0673cf19 Mon Sep 17 00:00:00 2001
Message-Id: <385013a1eff5855e500f7f6a2657260f0673cf19.1381382810.git.pagaltzis@gmx.de>
From: Aristotle Pagaltzis <pagaltzis@gmx.de>
Date: Thu, 10 Oct 2013 07:24:10 +0200
Subject: [PATCH] perldata: document corrected list slicing behaviour

---
 pod/perldata.pod | 25 ++++++++++---------------
 1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/pod/perldata.pod b/pod/perldata.pod
index 254884d..7dc4cde 100644
--- a/pod/perldata.pod
+++ b/pod/perldata.pod
@@ -879,26 +879,21 @@ values of the array or hash.
         s/(\w+)/\u\L$1/g;   # "titlecase" words
     }
-
-A slice of an empty list is still an empty list.  Thus:
-
-    @a = ()[1,0];           # @a has no elements
-    @b = (@a)[0,1];         # @b has no elements
-
-But:
-
-    @a = (1)[1,0];          # @a has two elements
-    @b = (1,undef)[1,0,2];  # @b has three elements
-
-More generally, a slice yields the empty list if it indexes only
-beyond the end of a list:
-
-    @a = (1)[  1,2];        # @a has no elements
-    @b = (1)[0,1,2];        # @b has three elements
+
+As a special exception, when you slice a list (but not an array or a hash),
+if the list evaluates to empty, then taking a slice of that empty list will
+always yield the empty list in turn.  Thus:
+
+    @a = ()[0,1];          # @a has no elements
+    @b = (@a)[0,1];        # @b has no elements
+    @c = (sub{}->())[0,1]; # @c has no elements
+    @d = ('a','b')[0,1];   # @d has two elements
+    @e = (@d)[0,1,8,9];    # @e has four elements
+    @f = (@d)[8,9];        # @f has two elements
 
 This makes it easy to write loops that terminate when a null list
 is returned:
 
-    while ( ($home, $user) = (getpwent)[7,0]) {
+    while ( ($home, $user) = (getpwent)[7,0] ) {
         printf "%-8s %s\n", $user, $home;
     }
 
-- 
1.8.3.4

@p5pRT
Copy link
Author

p5pRT commented May 12, 2014

From @rjbs

Aristotle, if you have fact-checked the changes against bleadperl, please feel
free to apply them ASAP.

--
rjbs

@p5pRT
Copy link
Author

p5pRT commented May 13, 2014

From jrw32982@gmail.com

See my reply below. It bounced when sending it from yahoo.

On Tue, May 13, 2014 at 8​:52 AM, John Wiersba <jrw32982@​yahoo.com> wrote​:

----- Forwarded Message -----
*From​:* John Wiersba <jrw32982@​yahoo.com>
*To​:* "perlbug-followup@​perl.org" <perlbug-followup@​perl.org>
*Sent​:* Tuesday, May 13, 2014 8​:42 AM
*Subject​:* Re​: [perl #114498] List slice *sometimes* ignores undefined
items

Thanks for this, Aristotle. I would consider adding one more contrasting
example​:

+ @​b = (@​a)[0,1]; # @​b has no elements
+ @​b = @​a[0,1]; # @​b has two elements # <= this is new

Also, you might consider adding a note that this is a change in behavior
from perls < 5.20, where a slice of an nonempty list would yield an empty
list when all the indexes were out of bounds.

-- John

------------------------------
*From​:* Aristotle Pagaltzis via RT <perlbug-followup@​perl.org>
*To​:* jrw32982@​yahoo.com
*Sent​:* Sunday, May 11, 2014 6​:28 AM
*Subject​:* Re​: [perl #114498] List slice *sometimes* ignores undefined
items

Hi perl5-porters,

* Aristotle Pagaltzis <pagaltzis@​gmx.de> [2014-05-11 12​:15]​:

* Aristotle Pagaltzis <pagaltzis@​gmx.de> [2014-03-11 08​:20]​:

Bump.

It would be nice for this to make it into 5.20.

Maybe if I try with the patch inlined it’ll get comments quicker. :-)

Also now as a patience diff, much nicer.

From 385013a1eff5855e500f7f6a2657260f0673cf19 Mon Sep 17 00​:00​:00 2001
Message-Id​: <
385013a1eff5855e500f7f6a2657260f0673cf19.1381382810.git.pagaltzis@​gmx.de>
From​: Aristotle Pagaltzis <pagaltzis@​gmx.de>
Date​: Thu, 10 Oct 2013 07​:24​:10 +0200
Subject​: [PATCH] perldata​: document corrected list slicing behaviour

---
pod/perldata.pod | 25 ++++++++++---------------
1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/pod/perldata.pod b/pod/perldata.pod
index 254884d..7dc4cde 100644
--- a/pod/perldata.pod
+++ b/pod/perldata.pod
@​@​ -879,26 +879,21 @​@​ values of the array or hash.
s/(\w+)/\u\L$1/g; # "titlecase" words
}
-
-A slice of an empty list is still an empty list. Thus​:
-
- @​a = ()[1,0]; # @​a has no elements
- @​b = (@​a)[0,1]; # @​b has no elements
-
-But​:
-
- @​a = (1)[1,0]; # @​a has two elements
- @​b = (1,undef)[1,0,2]; # @​b has three elements
-
-More generally, a slice yields the empty list if it indexes only
-beyond the end of a list​:
-
- @​a = (1)[ 1,2]; # @​a has no elements
- @​b = (1)[0,1,2]; # @​b has three elements
+
+As a special exception, when you slice a list (but not an array or a
hash),
+if the list evaluates to empty, then taking a slice of that empty list
will
+always yield the empty list in turn. Thus​:
+
+ @​a = ()[0,1]; # @​a has no elements
+ @​b = (@​a)[0,1]; # @​b has no elements
+ @​c = (sub{}->())[0,1]; # @​c has no elements
+ @​d = ('a','b')[0,1]; # @​d has two elements
+ @​e = (@​d)[0,1,8,9]; # @​e has four elements
+ @​f = (@​d)[8,9]; # @​f has two elements

This makes it easy to write loops that terminate when a null list
is returned​:

- while ( ($home, $user) = (getpwent)[7,0]) {
+ while ( ($home, $user) = (getpwent)[7,0] ) {
printf "%-8s %s\n", $user, $home;
}

--
1.8.3.4

@p5pRT
Copy link
Author

p5pRT commented Jun 16, 2014

From @khwilliamson

On 05/11/2014 04​:27 AM, Aristotle Pagaltzis wrote​:

Hi perl5-porters,

* Aristotle Pagaltzis <pagaltzis@​gmx.de> [2014-05-11 12​:15]​:

* Aristotle Pagaltzis <pagaltzis@​gmx.de> [2014-03-11 08​:20]​:

Bump.

It would be nice for this to make it into 5.20.

Maybe if I try with the patch inlined it’ll get comments quicker. :-)

Also now as a patience diff, much nicer.

What is the status on applying this?

@p5pRT
Copy link
Author

p5pRT commented Jun 16, 2014

From @ap

* Karl Williamson <public@​khwilliamson.com> [2014-06-16 22​:45]​:

What is the status on applying this?

The underlying core patch has not been applied and so this doc patch
cannot be either.

I found that FC’s patch no longer applies cleanly and made an ad-hoc
attempt to rebase it, but I ran out of time and put it on the back
burner.

And there it sits for now, on my todo list, along with my doc patch.

Regards,
--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

@p5pRT
Copy link
Author

p5pRT commented Dec 4, 2014

From @cpansprout

On Mon Jun 16 15​:26​:27 2014, aristotle wrote​:

* Karl Williamson <public@​khwilliamson.com> [2014-06-16 22​:45]​:

What is the status on applying this?

The underlying core patch has not been applied and so this doc patch
cannot be either.

I found that FC’s patch no longer applies cleanly and made an ad-hoc
attempt to rebase it, but I ran out of time and put it on the back
burner.

And there it sits for now, on my todo list, along with my doc patch.

I have applied my core patch as cbce292 and your doc patch as e2ec1b0. Thank you.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Dec 4, 2014

@cpansprout - Status changed from 'open' to 'pending release'

@p5pRT
Copy link
Author

p5pRT commented Dec 4, 2014

From @ap

* Father Chrysostomos via RT <perlbug-followup@​perl.org> [2014-12-04 03​:20]​:

I have applied my core patch as cbce292 and your doc patch as
e2ec1b0. Thank you.

Thank you! Another semantics bug fixed, hooray. :-)

@p5pRT
Copy link
Author

p5pRT commented Dec 4, 2014

From @cpansprout

On Thu Dec 04 06​:56​:03 2014, aristotle wrote​:

* Father Chrysostomos via RT <perlbug-followup@​perl.org> [2014-12-04 03​:20]​:

I have applied my core patch as cbce292 and your doc patch as
e2ec1b0. Thank you.

Thank you! Another semantics bug fixed, hooray. :-)

Speaking of semantics bugs, would you be willing to look at #123367?

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Dec 4, 2014

From [Unknown Contact. See original ticket]

On Thu Dec 04 06​:56​:03 2014, aristotle wrote​:

* Father Chrysostomos via RT <perlbug-followup@​perl.org> [2014-12-04 03​:20]​:

I have applied my core patch as cbce292 and your doc patch as
e2ec1b0. Thank you.

Thank you! Another semantics bug fixed, hooray. :-)

Speaking of semantics bugs, would you be willing to look at #123367?

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Jun 2, 2015

From @khwilliamson

Thanks for submitting this ticket

The issue should be resolved with the release today of Perl v5.22. If you find that the problem persists, feel free to reopen this ticket

--
Karl Williamson for the Perl 5 porters team

@p5pRT
Copy link
Author

p5pRT commented Jun 2, 2015

@khwilliamson - Status changed from 'pending release' to 'resolved'

@p5pRT p5pRT closed this as completed Jun 2, 2015
@p5pRT
Copy link
Author

p5pRT commented Jun 2, 2015

From jrw32982@gmail.com

From​: Karl Williamson via RT <perlbug-followup@​perl.org>
To​: jrw32982@​yahoo.com
Sent​: Monday, June 1, 2015 11​:40 PM
Subject​: [perl #114498] Your ticket against Perl 5 has been resolved

Thanks for submitting this ticket

The issue should be resolved with the release today of Perl v5.22. If you
find that the problem persists, feel free to reopen this ticket

--
Karl Williamson for the Perl 5 porters team

Thanks, Karl (and all of p5p)! The world will be a better place
because of your hard work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant