Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: [PATCH] (?) typeset array[position=index]=value
- X-seq: zsh-workers 49025
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Mikael Magnusson <mikachu@xxxxxxxxx>
- Cc: Zsh hackers list <zsh-workers@xxxxxxx>
- Subject: Re: [PATCH] (?) typeset array[position=index]=value
- Date: Sat, 5 Jun 2021 09:22:29 -0700
- Archived-at: <https://zsh.org/workers/49025>
- In-reply-to: <CAHYJk3S1aJ_XJiLv=qci798scNJZ_i5XovKUOn9o4z36WewvHQ@mail.gmail.com>
- List-id: <zsh-workers.zsh.org>
- References: <20191216211013.6opkv5sy4wvp3yn2@chaz.gmail.com> <20191216212706.i3xvf6hn5h3jwkjh@chaz.gmail.com> <20191217073846.4usg2hnsk66bhqvl@chaz.gmail.com> <20191217111113.z242f4g6sx7xdwru@chaz.gmail.com> <2ea6feb3-a686-4d83-ab27-6a582424487c@www.fastmail.com> <20200101140343.qwfx2xaojumuds3d@chaz.gmail.com> <20210430061117.buyhdhky5crqjrf2@chazelas.org> <CAH+w=7bHxSbFr60ZU0+oZ6+qEejhfBYTzvL7=aXadY5XzWtSzw@mail.gmail.com> <20210505114521.bemoiekpophssbug@chazelas.org> <CAH+w=7ZqE2DnxpHhvCjZnXB4A1vJ=EKB2fpWyUMaZX0VYqU9kg@mail.gmail.com> <CAH+w=7bVn2LiTsq194GjshVSOCSib7t4T=uZQ2ZvUGu6Z2XoPw@mail.gmail.com> <CAHYJk3RSDVjxAPhz5Z+1D31-tZtL5qFonokPY=tTauK8RzAXew@mail.gmail.com> <CAH+w=7aVdHRYCnpXdO6E+FwMoM5jvVvD+1am70k76ca8q5-WyQ@mail.gmail.com> <CAHYJk3S1aJ_XJiLv=qci798scNJZ_i5XovKUOn9o4z36WewvHQ@mail.gmail.com>
On Sat, Jun 5, 2021 at 4:06 AM Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
>
> On 6/5/21, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> >
> > foo=( [a]=() )
> remove foo[a]
That doesn't make sense. foo=( [a]=z ) replaces the entire hash table
with a single element.
foo=( [a]=() [b]=z )
would just be a very verbose way of saying foo=( b z ) ??
> > foo[a]=( z )
> set foo[a] to z
> > foo[a]=( x y )
> error
How is that any more consistent than what we have now?
> > etc.
> there probably aren't more cases
foo[(R)*a*]=( ... )
If we can assign one element to foo[a] with parens, why can't we
assign a list of elements?
> Since we've established that both unset and assignment to an element
> behaves in no way the same already for regular arrays and associative
> arrays, is there any reason to not make assignment to associative
> array slices (with the empty slice) just remove the element? The
> parsing already works and it wouldn't break any existing cases.
We can continue to have that discussion, but IMO that's orthogonal to
whether subscripts are parsed correctly by unset.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author