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

how to treat array access to not-permitted elements? #13

Open
happy-barney opened this issue Jun 2, 2023 · 2 comments
Open

how to treat array access to not-permitted elements? #13

happy-barney opened this issue Jun 2, 2023 · 2 comments

Comments

@happy-barney
Copy link
Collaborator

Example:

my @list : (Array[ max_length (7), Int ];

if ($list[8]) { # should this fail?
}
@druud
Copy link
Collaborator

druud commented Jun 2, 2023 via email

@Ovid
Copy link
Collaborator

Ovid commented Jun 4, 2023

In Perl, our data isn't just the "type" of the data (SV, IV, PV), but also the "shape" of the data (scalar, array, hash). I think any checks would have to consider both. Thus, we need array out-of-bounds errors.

Also, the MVP will not have compile-time errors because we're trying to constrain the scope as much as possible. I do see room for compile-time errors later.

Also, as for @druud's query regarding this:

my $t :UInt8;
$t |= 256;

It's a non-issue because the my $f :UInt8; would throw an exception because undef doesn't meet the constraint.

But if we have var:

var $t :of(UInt8);
$t |= 256;

The error would appear on the second line because you can coerce an undefined value, but not an uninitialized one. However, that would like leak out of the existing scope and cause grief elsewhere in unsuspecting code (which it should do, to be fair), but people would scream, so I'm pretty sure that var is not just out of scope for this MVP, but also impossible to get P5P to accept (what would happen with $array[$i] where $i is an uninitialized var? I should throw an exception).


As an aside, if we do attributes for the checks, we can't do :UInt8 because there are so many checks that we'd have massive pollution of the attribute "namespace" and would be much more like to cause conflicts with existing code.

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

3 participants