Don't treat out-of-bounds differently than undefined variables

set a b; echo $a[1] yields b, while set a b; echo $a[2] yields the error fish: Could not expand string “$a[2]”.

Meanwhile, echo $a[2] without setting anything simply yields an empty string. This seems kind of like an odd behaviour, and there's no reason that there should be an error if you go out of bounds on an array when there isn't one for undefined variables.

[ridiculousfish]

I think I agree.

[dag]

#805 is relevant.

[JeanMertz]

I am running into this myself. So how can I work around this right now? Say I have a function that accepts multiple arguments, but they are not required.

If I do

test -n "$argv[2]"; set -x MYVAR $argv[2]

this will fail with the fish: Could not expand string “$argv[2]” error. I haven't found a way to only set MYVAR if $argv[2] is set. I'm sure I am missing something obvious here.

[maxfl]

you can use 'set -q' to test variable

set -q argv[2]

[terlar]

Another way is to use the read function:

echo $argv | read -l first second last
test -n "$second"; and set -x MYVAR $second

This will assign the variables if they exist and if you have more they will all be assigned to the last one. The usefulness of this depends on your use case of course.

[JeanMertz]

Thanks for the help guys. I did try set -q argv[2] before, but it failed to work, not I noticed I forgot the and after the ;, making the test not relevant anymore.

Also, thanks for the read solution @teriar, I ended up using that as well. It looks nice and clean.

I'm going to bump this to add that invalid slices should also fit under this category. It'd make it easier to make $argv[1] go to one command and $argv[2..-1] go to another even if you only supply one argument.

[sugar700]

Invalid slices should return empty array in my opinion. There are some reasons to use invalid slices. For example, if you have some function that takes infinite arguments from second position, $argv[2..-1] (or even $argv[2..], perhaps...) would be very logical, but it doesn't work with argv containing just one element.

It would cause $argv[2] and $argv[2..2] to do different stuff, but in my opinion, it isn't a problem. For prior art, see Python or Perl 6 (but in Perl 6, it only affects ranges with negative ending, like @array[1..*-1] (or even @array[1..*])).

[maxfl]

@glitchmr, agree about slices, I will update the code on this.

[brandonweiss]

Any word on this? I just got bit by it.

[davidpelaez]

Same for me, the notion of default empty slice should be used, pretty much the same way that echo $undefinedsomething yields an empty string 👍

#1474 also goes along with this.

[lilyball]

In current master the set vs unset variable inconsistency is gone. $a[2] is an error when $a doesn't exist just as it is when $a does exist and has 0 or 1 elements. Note that $a[1] is always valid even if $a has zero elements, primarily because it's just too annoying to have that be an error.

---

I talked about this issue in #1656. I would very much like to get rid of all "out of bounds" errors. I believe that ranges and indexes need to behave the same though, so $foo[2] is identical to $foo[2..2]. The two options for handling this:

1. Any out of bounds index evaluates to the empty string "". Note that $foo[5..-1] where $foo has fewer than 5 elements will evaluate to an empty range and therefore zero elements.
2. Out of bounds indexes evaluate to nothing.

At this point I think we should go with approach 2, as I think it makes more sense, and it's consistent with the behavior of $a[1] today.

---

A third option that extends approach 2 is to add syntax to denote the default value that should be used for any indexes that don't exist. This could always be added later of course. My worry with this is that it adds complexity, but the motivation for doing so is that, while you could write a function for providing a default for a single value (default val $var), you can't do so for ranges or index collections because you wouldn't know where to insert it into the result. This could possibly look like $foo[1..3 or '']. I think it's worth considering this, but at this point I think it should be deferred and re-considered at some point in the future.