Re: [PATCH] (take two?) typeset array[position=index]=value / unset hash[$stuff]

[Bart Schaefer <schaefer@brasslantern.com>]

On Wed, Jun 2, 2021 at 3:06 AM Stephane Chazelas <stephane@chazelas.org> wrote:
>
> 2021-06-01 19:51:32 -0700, Bart Schaefer:
> [...]
> > > The issue with the empty key seems merely to be that the subscript
> > > validity test for associative arrays never changed from the one for
> > > plain arrays.
> >
> > To maintain error-equivalent backward compatibility I didn't "fix"
> > this, instead, hash[(e)] (or hash[(e)''] if you think that more
> > readable) is required in order to unset the element with the empty
> > key.
>
> I have to admit I don't see the problem here. I would have
> thought allowing a[]=foo and unset 'a[]' would be no-brainers

Mostly I was thinking about

key=$(some derived value)
unset "hash[$key]"

In existing code that would fail on [[ -z $key ]], but you can't see
that by examination.

> as there's no concern about backward compatibility as those
> currently return an error.

That's not our usual criteria for backward compatibility.  Usually we
only change things if the new construct was previously a syntax error,
something that would prevent an old script from even being properly
parsed.

> Even for plain arrays, IMO, it would make sense to allow empty
> subscripts. In most contexts, an empty arithmetic expression is
> interpreted as 0:

But ... there's no such thing as array position 0 in native zsh.

> unset "a[(e)$key]"
>
> That still chokes on ()[]`\ and that still can't be worked around

This is why I asked for test cases ... combinations that I tried DID
work with a[(e)$key].  So, that may be a deal-breaker regardless of
the rest of this discussion.

> It's also a bit confusing that subscript flags would be
> seemingly parsed but later ignored (included in the value of the
> key) except for (e).

Well, they're parsed and ignored currently, and we already allow some
subscripts but not others in various assignment contexts, so this
doesn't seem all that weird in comparison.

> The fact that (e) is recognised and (ee) is
> not also makes for a not very consistent API.

What would (ee) mean?