Re: [PATCH] Optimization of getarrvalue()

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

On Mon, 14 Nov 2016 21:32:19 +0900
"Jun T." <takimoto-j@kba.biglobe.ne.jp> wrote:
> The original (before a1633e0) behavior is already quite
> confusing to me. For example,
> 
> zsh% nargs "${(@)a[i]}"
> 
> will output 0 only for i=0. On the other hand
> 
> zsh% nargs "${(@)a[i,i]}"
> 
> will output 0 for i=0 and 2.

0 is an invalid subscript, which is probably the difference in the first
case between it and other values.

> If I replace
>    arrlen_lt(s, v->start) by arrlen_le(s, v->start)
> (which may look reasonable since the array s[] is 0-based)
> then nargs "${(@)a[i,i]}" will output 0 only for i=0.
> But then "make check" fails in two tests (D04parameter and
> Y01completion).

The parameter test is testing

setopt rcexpandparam
local -A hash=(X x)                       
print LOST key=$hash[(I)y] val=$hash[(R)Y]

outputs LOST with the arguments removed.  With your change you get an
array wth an empty element and that doesn't happen.

I guess the differences are to do with the way the value of the end
index is used, with the hash case apparently behaving more like an array
slice than an invidivudal index and the latter being the odd one out
(but also the most commonly used case).  It may be too late to
disentangle this.

pws