Re: [PATCH] Optimization of getarrvalue()

[Bart Schaefer <schaefer@brasslantern.com>]

On Nov 15,  7:57pm, Peter Stephenson wrote:
}
} > 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.

An array with an empty element would be wrong in either of those caes.
(Sebastian reported the same thing when he tried removing s[0]=NULL
from one branch in his original patch.)

} 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

Yes, intentionally so -- (I) and (R) are defined on hashes to return
*all* the possible matches for the pattern, so the result is an array
even if there is only one matching element.  If you want a single
element, use (i) or (r).  Hashes don't have an ordering, so it's
meaningless to distinguish between the "first" and "last" elements.
("First" just means "most easily identified".)

} and the latter being the odd one out
} (but also the most commonly used case).  It may be too late to
} disentangle this.

Semantically, I don't think there's anything to disentangle?  As for
the implementation it might be nice not to have to reduce a hash to an
array of either keys or values quite so frequently, as that might have
avoided this confusion by never treating a hash as though it has any
numeric indices.