[perl #131705] constant Regex: getlex: outer index out of range

[via RT]

# New Ticket Created by  Lloyd Fournier 
# Please include the string:  [perl #131705]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=131705 >


echo 'constant @foo is export  = /{ say "hello" } ./, > Foo.pm6

perl6 -I. -e 'use Foo; "foo" ~~ @foo[0];

# getlex: outer index out of range

This is another compile time outer lexical scope bug. Note: the array is
superfluous, just there to avoid triggering RT #131704.

[perl #131704] Can't use unknown trait 'is export' in a regex declaration

[via RT]

# New Ticket Created by  Lloyd Fournier 
# Please include the string:  [perl #131704]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=131704 >


perl6 -e 'constant $foo is export = /foo/;'

 seems to be being called on the regex rather than the variable??

[perl #131703] [IO] [REGRESSION] Command line arguments try and open as a file

[via RT]

# New Ticket Created by  Samantha McVey 
# Please include the string:  [perl #131703]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=131703 >


Here is the offending code
https://gist.github.com/9ed8322b4c9e1a40e1f3df495d8cee1d (not written by
me).

If you run it normally with no arguments and just press enter till the
end of execution, there are no issues. If you run `perl6 deckofpain.p6
easy` at the end of execution you get


Failed to open file /home/samantha/proj/perl6/easy: No such file or
directory
  in sub MAIN at deck-of-pain.p6 line 127
  in block  at deck-of-pain.p6 line 30


This is the commit that introduced this regression:

[io grant] Swap IO::ArgFiles to IO::CatHandle impl

https://github.com/rakudo/rakudo/commit/f539a624043f5796fcefcca83412ee1ab66e0c4d

Re: Version of a Module

[Lloyd Fournier]

It is a bug. It's because of the way require is implemented at the moment
is a little rough. The first one is asking for the .^ver of a stub package
require has inserted. ::("Bailador").ver should work.

LL

On Wed, Jul 5, 2017 at 4:46 AM Martin Barth  wrote:

> Hi there,
>
> is this a bug?
>
> > perl6 -Ilib -e 'require Bailador; say Bailador.^ver'
> No such method 'ver' for invocant of type 'Perl6::Metamodel::PackageHOW'
>   in block  at -e line 1
>
> vs
>
> > perl6 -Ilib -e 'use Bailador; say Bailador.^ver'
> v0.0.7
>
> it seems that there a 2 different metaclasses being used:
>
> > perl6 -Ilib -e 'use Bailador; say Bailador.HOW'
> Perl6::Metamodel::ModuleHOW.new
>
> > perl6 -Ilib -e 'require Bailador; say Bailador.HOW'
> Perl6::Metamodel::PackageHOW.new
>
> Am 28.06.2017 um 14:16 schrieb Simon Proctor:
>
> See I'm using mi6 to generate my META6.json file from the report and it
> picks the version up from the module file. Other options like that seem
> sensible to me.
>
> Simon
>
> On Wed, 28 Jun 2017, 13:01 Martin Barth,  wrote:
>
>> Hello,
>>
>> but your approach means you have to state the version in the META6.json
>> AND in the Module.pm6 file again. This would be the similar to having
>> $VERSION in perl5. Shouldnt there be a simpler way?
>>
>>
>> Am 28.06.2017 um 08:45 schrieb Fernando Santagata:
>>
>> Hi Martin,
>>
>> This works for me:
>>
>> File mytest.pm6
>>
>> use v6;
>> unit module mytest:ver<0.0.1>;
>>
>> sub myver is export
>> {
>>   mytest.^ver;
>> }
>>
>> File mytest.p6
>>
>> #!/usr/bin/env perl6
>> use lib '.';
>> use mytest;
>>
>> say myver;
>>
>> Console output:
>>
>> $./mytest.p6
>> v0.0.1
>>
>> I this what you meant?
>>
>> On Tue, Jun 27, 2017 at 10:37 PM, Martin Barth  wrote:
>>
>>> Hello everyone,
>>>
>>> I wanted to repeat the question that I asked today on #perl6.
>>> I am looking for a way to retrieve the version of a Perl6-Module from
>>> within the module itself.
>>>
>>>  there is often a our $VERSION in perl5 modules. is this still
>>> idiomatic/a good way to go in perl6
>>>  i think the version is meant to be part of the meta info and
>>> such?
>>>  but that means the module itself does not know about its
>>> version, just e.g. zef does?
>>>  i'm convinced there ought to be a way to get the full meta
>>> info from whatever installation your script was grabbed from
>>>  but i don't know what or how
>>>
>>
>>
>>
>> --
>> Fernando Santagata
>>
>>
>>
>

[perl #131700] [IO] prompt not working on bash-on-ubuntu on win10

[via RT]

# New Ticket Created by  gfw blackcat 
# Please include the string:  [perl #131700]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=131700 >


In bash on win10

Code:

perl6 --ll-exception -e ' prompt "123" '

Output:

123
Cannot flush handle: Failed to flush filehandle: Input/output error
   at SETTING::src/core/Exception.pm:63
(/usr/share/perl6/runtime/CORE.setting.moarvm:throw)
 from SETTING::src/core/Failure.pm:44
(/usr/share/perl6/runtime/CORE.setting.moarvm:throw)
 from SETTING::src/core/Failure.pm:86
(/usr/share/perl6/runtime/CORE.setting.moarvm:sink)
 from SETTING::src/core/io_operators.pm:89
(/usr/share/perl6/runtime/CORE.setting.moarvm:prompt)
 from SETTING::src/core/io_operators.pm:83
(/usr/share/perl6/runtime/CORE.setting.moarvm:prompt)
 from -e:1  (:)
 from -e:1  (:)
 from gen/moar/stage2/NQPHLL.nqp:1589
(/usr/share/nqp/lib/NQPHLL.moarvm:eval)
 from gen/moar/stage2/NQPHLL.nqp:1696  (/usr/share/nqp/lib/NQPHLL.moarvm:)
 from gen/moar/stage2/NQPHLL.nqp:1731
(/usr/share/nqp/lib/NQPHLL.moarvm:command_eval)
 from src/Perl6/Compiler.nqp:42
(/usr/share/nqp/lib/Perl6/Compiler.moarvm:command_eval)
 from gen/moar/stage2/NQPHLL.nqp:1677
(/usr/share/nqp/lib/NQPHLL.moarvm:command_line)
 from gen/moar/main.nqp:47  (/usr/share/perl6/runtime/perl6.moarvm:MAIN)
 from gen/moar/main.nqp:38
(/usr/share/perl6/runtime/perl6.moarvm:)
 from :1  (/usr/share/perl6/runtime/perl6.moarvm:)
 from :1  (/usr/share/perl6/runtime/perl6.moarvm:)

perl6 -v output:

This is Rakudo version 2017.06 built on MoarVM version 2017.06
implementing Perl 6.c.

[perl #130366] BagHash/MixHash values don't check for zeroness

[Aleks-Daniel Jakimenko-Aleksejev via RT]

This was resolved together with
https://rt.perl.org/Ticket/Display.html?id=131241

Tests needed, maybe. See other ticket for info on this.
On 2016-12-17 01:42:04, elizabeth wrote:
> $ 6 'my $b = .BagHash; $_-- for $b.values; dd $b'
> BagHash $b = ("a"=>0,"c"=>0,"b"=>1,"e"=>0,"f"=>0,"d"=>0).BagHash
> *SHOULD* be BagHash $b = ("b"=>1).BagHash
>
>
> $ 6 'my $b = .BagHash; .value-- for $b.pairs; dd $b'
> BagHash $b = ("a"=>0,"c"=>0,"b"=>1,"e"=>0,"f"=>0,"d"=>0).BagHash
> *SHOULD* be BagHash $b = ("b"=>1).BagHash
>
>
> $ 6 'my $b = .BagHash; $_ = 0 for $b.values; dd $b'
> BagHash $b = ("a"=>0,"c"=>0,"b"=>0,"e"=>0,"f"=>0,"d"=>0).BagHash
> *SHOULD* be BagHash $b = ("b"=>1).BagHash
>
>
> Same for MixHash. Baggy/Mixy need to have the equivalent logic to
> ISINSET from SetHash.
>
>
> RTing this so it won’t fall through the cracks.

[perl #131241] (Bag|Mix)Hash.values doesn't check validity of assigned values

[Aleks-Daniel Jakimenko-Aleksejev via RT]

The fix for this ticket also fixed
https://rt.perl.org/Public/Bug/Display.html?id=130366

However, we couldn't find any tests… are there any? If they, perhaps they also
cover 130366.

On 2017-05-01 14:31:19, elizabeth wrote:
> Fixed for the .values case with c1bd844e2752799af8e and
> 0e0ac2fb8c51a82a0 . But this needs a more thorough fix. To be
> forthcoming soon!
>
> > On 1 May 2017, at 19:28, Elizabeth Mattijsen (via RT)  > follo...@perl.org> wrote:
> >
> > # New Ticket Created by Elizabeth Mattijsen
> > # Please include the string: [perl #131241]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=131241 >
> >
> >
> >  m: my $b = .BagHash; $_ = 0 for $b.values;
> > dd $b
> >  rakudo-moar 1f80db: OUTPUT: «BagHash $b =
> > ("b"=>0,"a"=>0,"c"=>0).BagHash␤»
> >  m: my $b = .BagHash; $_ = -1 for
> > $b.values; dd $b
> >  rakudo-moar 1f80db: OUTPUT: «BagHash $b = ("b"=>-
> > 1,"a"=>-1,"c"=>-1).BagHash␤»
> >  m: my $b = .MixHash; $_ = 0 for $b.values;
> > dd $b
> >  rakudo-moar 1f80db: OUTPUT: «MixHash $b =
> > ("b"=>0,"a"=>0,"c"=>0).MixHash␤»
> >
> > All should empty out the BagHash/MixHash.

[perl #131137] Throw out TAP.pm from core

[Zoffix Znet via RT]

Done in 
https://github.com/rakudo/rakudo/commit/ae891f93676fdf412c7e8fa517f5bda2bd6a41d6

Re: Version of a Module

[Martin Barth]

Hi there,

is this a bug?

> perl6 -Ilib -e 'require Bailador; say Bailador.^ver'
No such method 'ver' for invocant of type 'Perl6::Metamodel::PackageHOW'
  in block  at -e line 1

vs

> perl6 -Ilib -e 'use Bailador; say Bailador.^ver'
v0.0.7

it seems that there a 2 different metaclasses being used:

> perl6 -Ilib -e 'use Bailador; say Bailador.HOW'
Perl6::Metamodel::ModuleHOW.new

> perl6 -Ilib -e 'require Bailador; say Bailador.HOW'
Perl6::Metamodel::PackageHOW.new


Am 28.06.2017 um 14:16 schrieb Simon Proctor:


See I'm using mi6 to generate my META6.json file from the report and 
it picks the version up from the module file. Other options like that 
seem sensible to me.


Simon


On Wed, 28 Jun 2017, 13:01 Martin Barth, > wrote:


Hello,

but your approach means you have to state the version in the
META6.json AND in the Module.pm6 file again. This would be the
similar to having $VERSION in perl5. Shouldnt there be a simpler way?


Am 28.06.2017 um 08:45 schrieb Fernando Santagata:


Hi Martin,

This works for me:

File mytest.pm6

use v6;
unit module mytest:ver<0.0.1>;

sub myver is export
{
  mytest.^ver;
}

File mytest.p6

#!/usr/bin/env perl6
use lib '.';
use mytest;

say myver;

Console output:

$./mytest.p6
v0.0.1

I this what you meant?

On Tue, Jun 27, 2017 at 10:37 PM, Martin Barth > wrote:

Hello everyone,

I wanted to repeat the question that I asked today on #perl6.
I am looking for a way to retrieve the version of a
Perl6-Module from within the module itself.

 there is often a our $VERSION in perl5 modules. is
this still idiomatic/a good way to go in perl6
 i think the version is meant to be part of the
meta info and such?
 but that means the module itself does not know about
its version, just e.g. zef does?
 i'm convinced there ought to be a way to get the
full meta info from whatever installation your script was
grabbed from
 but i don't know what or how




-- 
Fernando Santagata

[perl #131695] [LTA] Confusion in precedence with <<$foo>>[0]

[Larry Wall via RT]

We now warn on the ambiguity of >> or » when used where it could easily be 
intended as either a hyper or the quotewords terminator.  While we could, in 
theory, do some lookahead to try to suppress this warning in some cases, it 
will be brittle in the face of languages that mutate the postfix space, so I 
think it's better to just warn outright and let people disambiguate with 
whitespace or a suitable change to the hyper or quote delims.

(As for retargeting this ticket to the more general case of multiline quote 
errors, please note that a runaway hyper is not a kind of quote, and that we 
already warning on runaway quotes that cross line boundaries.  Also, the 
problem here is essentially independent of multi-line-ness.  So I've changed 
the title of this bug back to the original, since that's the problem we're 
fixing.)

[perl #131701] [PARSER] Failure to parse `[[],]`

[via RT]

# New Ticket Created by  Zoffix Znet 
# Please include the string:  [perl #131701]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=131701 >


Works (space between brackets and ):

$ perl6 -e 'dd [[ ],]'
[["a"],]

Doesn't (no space):

$ perl6 -e 'dd [[],]'
===SORRY!=== Error while compiling -e
Unable to parse expression in bracketed infix; couldn't find final ']' 
at -e:1
--> dd [[<⏏a>],]

[perl #131699] [LTA] Errors indexing past the end of a List

[Zoffix Znet via RT]

On Tue, 04 Jul 2017 07:20:50 -0700, elizabeth wrote:
> > Hm. Wouldn't that make behavior of Lists and Arrays different?
> 
> No, because Lists are supposed to be immutable wrt to the number of
> elements.

Yes, but that doesn't mean the user of the list necessarily knows or has to 
know how many elements the list has, to look up an element by index, without 
things exploding.

> generate a Failure on out of bounds value

IMO that's the wrong approach and the current behaviour of returning Nil is 
most desirable. Consider this code:

sub do-stuff (@args) {
say @args[0] + 1;
}

do-stuff [];
do-stuff ();

If you Fatalise past-end .AT-POS on Lists that sub will now work fine with 
Arrays, but crash with Lists. So as a consumer of `@args` Iterable, I'm now 
faced with two potential behaviours and have to account for Exceptions.

Currently, the code will also produce a warning, as do many things that consume 
a Nil where Nil doesn't really belong. IMO that's a good-enough warning for the 
inadvertent out-of-bounds access.

By adding the Failure, we also end up with another inconsistency that `my ($a, 
$b) = @list` would work and assign Nil to `$b` when `@list` has just one 
element, but `my ($a, $b) = @list[0,1]` would assign a Failure to it. Lastly, 
we'd have `@list[0,1]` return a list with 1 value and 1 Failure in it (call 
.elems on it and the Failure's silently gone).

So, IMO, yes, we could change "0..^Inf" to tell number of actual elements, but 
that error is fundamentally different from trying to access past List's end, 
because you can NEVER access element at index -1, yet you can access index N, 
and we should leave the "return Nil" behaviour as is and not deviate from Array 
behaviour.

[perl #131699] [LTA] Errors indexing past the end of a List

[Zoffix Znet via RT]

On Tue, 04 Jul 2017 07:20:50 -0700, elizabeth wrote:
> > Hm. Wouldn't that make behavior of Lists and Arrays different?
> 
> No, because Lists are supposed to be immutable wrt to the number of
> elements.

Yes, but that doesn't mean the user of the list necessarily knows or has to 
know how many elements the list has, to look up an element by index, without 
things exploding.

> generate a Failure on out of bounds value

IMO that's the wrong approach and the current behaviour of returning Nil is 
most desirable. Consider this code:

sub do-stuff (@args) {
say @args[0] + 1;
}

do-stuff [];
do-stuff ();

If you Fatalise past-end .AT-POS on Lists that sub will now work fine with 
Arrays, but crash with Lists. So as a consumer of `@args` Iterable, I'm now 
faced with two potential behaviours and have to account for Exceptions.

Currently, the code will also produce a warning, as do many things that consume 
a Nil where Nil doesn't really belong. IMO that's a good-enough warning for the 
inadvertent out-of-bounds access.

By adding the Failure, we also end up with another inconsistency that `my ($a, 
$b) = @list` would work and assign Nil to `$b` when `@list` has just one 
element, but `my ($a, $b) = @list[0,1]` would assign a Failure to it. Lastly, 
we'd have `@list[0,1]` return a list with 1 value and 1 Failure in it (call 
.elems on it and the Failure's silently gone).

So, IMO, yes, we could change "0..^Inf" to tell number of actual elements, but 
that error is fundamentally different from trying to access past List's end, 
because you can NEVER access element at index -1, yet you can access index N, 
and we should leave the "return Nil" behaviour as is and not deviate from Array 
behaviour.

Re: [perl #131699] [LTA] Errors indexing past the end of a List

[Elizabeth Mattijsen via RT]

> On 4 Jul 2017, at 16:19, Elizabeth Mattijsen  wrote:
> That said, a List may not always be completely reified already.  So 
> logically, a List may  have 100 elements, it could well be that only 42 of 
> these elements exist already.  Which means that the underlying NQP array, 
> which *is* mutable, only has 42 elements.  But it cannot know offhand whether 
> those are all possible elements, as that depends on the iterator that is 
> being used to fill the NQP array.
> 
> A complicating factor is that this is a very hot code path, so any changes 
> there could affect general performance significantly.  My initial tests to 
> generate a Failure on out of bounds value immediately results in 2 internal 
> errors trying to generate backtrace  :-(
> 
> Anyways, I agree with brian’s feelings on this.  The challenge is now to make 
> it so without making everything significantly slower.
> 
> FWIW, the code in question lives around line 480 in List.pm.

An example of a List that will never be fully reified:

  $ 6 'my $l = ^Inf .list; dd $l.^name; dd $l[10]'
  "List"
  10


Liz

Re: [perl #131699] [LTA] Errors indexing past the end of a List

[Elizabeth Mattijsen]

> On 4 Jul 2017, at 16:19, Elizabeth Mattijsen  wrote:
> That said, a List may not always be completely reified already.  So 
> logically, a List may  have 100 elements, it could well be that only 42 of 
> these elements exist already.  Which means that the underlying NQP array, 
> which *is* mutable, only has 42 elements.  But it cannot know offhand whether 
> those are all possible elements, as that depends on the iterator that is 
> being used to fill the NQP array.
> 
> A complicating factor is that this is a very hot code path, so any changes 
> there could affect general performance significantly.  My initial tests to 
> generate a Failure on out of bounds value immediately results in 2 internal 
> errors trying to generate backtrace  :-(
> 
> Anyways, I agree with brian’s feelings on this.  The challenge is now to make 
> it so without making everything significantly slower.
> 
> FWIW, the code in question lives around line 480 in List.pm.

An example of a List that will never be fully reified:

  $ 6 'my $l = ^Inf .list; dd $l.^name; dd $l[10]'
  "List"
  10


Liz

Re: [perl #131699] [LTA] Errors indexing past the end of a List

[Elizabeth Mattijsen via RT]

> On 4 Jul 2017, at 16:05, Aleks-Daniel Jakimenko-Aleksejev via RT 
>  wrote:
> On 2017-07-04 05:29:20, comdog wrote:
>> Accessing a List element beyond the end of the List returns Nil,
>> although accessing an element before the beginning returns an out of
>> bounds failure. I think there's two things that can be better here
>> since we know the size of the List.
>> 
>> my $list = < a b c >;
>> put "I have a {$list.^name}";
>> 
>> First, in the "before" case, we have more information than the error
>> message lets on. The index should be from 0 to 2:
>> 
>> {
>> my $i = -1;
>> $list[$i]; # Index out of range. Is: -1, should be in 0..^Inf
>> }
>> 
>> But this requires the change I think is more helpful. Since the List
>> size won't change, we can have the same out-of-bounds error on
>> accesses past the end. At the moment it's no warning:
>> 
>> {
>> my $i = $list.end + 1;
>> $list[$i]; # No warning
>> }
>> 
>> This would then be the error for assigning into a position beyond the
>> end. The existing error doesn't say what went wrong even though Perl 6
>> has enough information to figure that out:
>> 
>> {
>> my $i = $list.end + 1;
>> $list[$i] = 5; # Cannot modify an immutable Nil
>> }
> Hm. Wouldn't that make behavior of Lists and Arrays different?

No, because Lists are supposed to be immutable wrt to the number of elements.

That said, a List may not always be completely reified already.  So logically, 
a List may  have 100 elements, it could well be that only 42 of these elements 
exist already.  Which means that the underlying NQP array, which *is* mutable, 
only has 42 elements.  But it cannot know offhand whether those are all 
possible elements, as that depends on the iterator that is being used to fill 
the NQP array.

A complicating factor is that this is a very hot code path, so any changes 
there could affect general performance significantly.  My initial tests to 
generate a Failure on out of bounds value immediately results in 2 internal 
errors trying to generate backtrace  :-(

Anyways, I agree with brian’s feelings on this.  The challenge is now to make 
it so without making everything significantly slower.

FWIW, the code in question lives around line 480 in List.pm.


Liz

Re: [perl #131699] [LTA] Errors indexing past the end of a List

[Elizabeth Mattijsen]

> On 4 Jul 2017, at 16:05, Aleks-Daniel Jakimenko-Aleksejev via RT 
>  wrote:
> On 2017-07-04 05:29:20, comdog wrote:
>> Accessing a List element beyond the end of the List returns Nil,
>> although accessing an element before the beginning returns an out of
>> bounds failure. I think there's two things that can be better here
>> since we know the size of the List.
>> 
>> my $list = < a b c >;
>> put "I have a {$list.^name}";
>> 
>> First, in the "before" case, we have more information than the error
>> message lets on. The index should be from 0 to 2:
>> 
>> {
>> my $i = -1;
>> $list[$i]; # Index out of range. Is: -1, should be in 0..^Inf
>> }
>> 
>> But this requires the change I think is more helpful. Since the List
>> size won't change, we can have the same out-of-bounds error on
>> accesses past the end. At the moment it's no warning:
>> 
>> {
>> my $i = $list.end + 1;
>> $list[$i]; # No warning
>> }
>> 
>> This would then be the error for assigning into a position beyond the
>> end. The existing error doesn't say what went wrong even though Perl 6
>> has enough information to figure that out:
>> 
>> {
>> my $i = $list.end + 1;
>> $list[$i] = 5; # Cannot modify an immutable Nil
>> }
> Hm. Wouldn't that make behavior of Lists and Arrays different?

No, because Lists are supposed to be immutable wrt to the number of elements.

That said, a List may not always be completely reified already.  So logically, 
a List may  have 100 elements, it could well be that only 42 of these elements 
exist already.  Which means that the underlying NQP array, which *is* mutable, 
only has 42 elements.  But it cannot know offhand whether those are all 
possible elements, as that depends on the iterator that is being used to fill 
the NQP array.

A complicating factor is that this is a very hot code path, so any changes 
there could affect general performance significantly.  My initial tests to 
generate a Failure on out of bounds value immediately results in 2 internal 
errors trying to generate backtrace  :-(

Anyways, I agree with brian’s feelings on this.  The challenge is now to make 
it so without making everything significantly slower.

FWIW, the code in question lives around line 480 in List.pm.


Liz

[perl #131699] [LTA] Errors indexing past the end of a List

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Hm. Wouldn't that make behavior of Lists and Arrays different?

On 2017-07-04 05:29:20, comdog wrote:
> Accessing a List element beyond the end of the List returns Nil,
> although accessing an element before the beginning returns an out of
> bounds failure. I think there's two things that can be better here
> since we know the size of the List.
>
> my $list = < a b c >;
> put "I have a {$list.^name}";
>
> First, in the "before" case, we have more information than the error
> message lets on. The index should be from 0 to 2:
>
> {
> my $i = -1;
> $list[$i]; # Index out of range. Is: -1, should be in 0..^Inf
> }
>
> But this requires the change I think is more helpful. Since the List
> size won't change, we can have the same out-of-bounds error on
> accesses past the end. At the moment it's no warning:
>
> {
> my $i = $list.end + 1;
> $list[$i]; # No warning
> }
>
> This would then be the error for assigning into a position beyond the
> end. The existing error doesn't say what went wrong even though Perl 6
> has enough information to figure that out:
>
> {
> my $i = $list.end + 1;
> $list[$i] = 5; # Cannot modify an immutable Nil
> }

[perl #131699] [LTA] Errors indexing past the end of a List

[brian d foy]

# New Ticket Created by  "brian d foy" 
# Please include the string:  [perl #131699]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=131699 >


Accessing a List element beyond the end of the List returns Nil,
although accessing an element before the beginning returns an out of
bounds failure. I think there's two things that can be better here
since we know the size of the List.

my $list = < a b c >;
put "I have a {$list.^name}";

First, in the "before" case, we have more information than the error
message lets on. The index should be from 0 to 2:

{
my $i = -1;
$list[$i];  # Index out of range. Is: -1, should be in 0..^Inf
}

But this requires the change I think is more helpful. Since the List
size won't change, we can have the same out-of-bounds error on
accesses past the end. At the moment it's no warning:

{
my $i = $list.end + 1;
$list[$i]; # No warning
}

This would then be the error for assigning into a position beyond the
end. The existing error doesn't say what went wrong even though Perl 6
has enough information to figure that out:

{
my $i = $list.end + 1;
$list[$i] = 5;  # Cannot modify an immutable Nil
}