Re: [PATCH] (?) typeset array[position=index]=value

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On 6/5/21, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Fri, Jun 4, 2021 at 9:29 PM Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
>>
>> On 5/31/21, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>> > All tests still pass, but as you can see from the comment this is not
>> > yet handling x+=y which there doesn't seem to be any reason for
>> > typeset NOT to support; I think it would require only another flag in
>> > struct asgment, but I haven't attempted that.
>> >
>> > Commentary?
>>
>> Is there some fundamental reason we couldn't just make the obvious
>> thing work instead?
>
> For one thing, because the above isn't about what happens to the
> value, it's about whether assignment can understand the key?

Well, there was 4 different threads about saying "unset foo[$bar]" and
I didn't know exactly where to reply so I went to the source, maybe I
went one thread too far back though.

>> % typeset -A foo
>> % foo=(a b c d)
>> % foo[a]=()
>> # what actually happens
>> zsh: foo: attempt to set slice of associative array
>> # what seems reasonable to happen
>> % typeset -p foo
>> typeset -A foo=( [c]=d )
>
> The problem is with the follow-up questions, namely ,what should happen
> with
>
> foo=( [a]=() )
remove foo[a]
> foo[a]=( z )
set foo[a] to z
> foo[a]=( x y )
error
> etc.
there probably aren't more cases

>> Relatedly, this also seems very inconsistent:
> [...]
>> So for regular arrays, unset will just set the element to the empty
>> string, for assoc arrays it removes the key and the value.
>
> That's because zsh doesn't support sparse arrays, and the NULL element
> indicates the end of the array, so you can't put a NULL element in the
> middle.  If we'd thought about it long ago, it might be an error to
> unset a regular array element, but we're stuck now.
>
>> For regular arrays, assigning () to the element unsets(?) the element
>
> No.  For regular arrays assigning an array to an element splices the
> rvalue array into the lvalue array.   Splicing the empty array
> shortens the regular array, it doesn't cause elements to become unset
> (unless you consider that the former $#'th element is now unset
> because that position no longer exists).

By this logic, unset "foo[bar]" should have had the same effect as
foo[bar]="" (also too late).

>> and for assoc arrays it is an error.
>
> Because you can't perform a splice on a hash table.

Well, with my naive end user hat, this seems much more logical to
remove an element than fiddling with the unset keyword, which doesn't
even do the same on a normal array. If you come from knowing that
bar[5]=() removes the 5th element, then it's reasonable to assume that
foo[baz]=() would work too.

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.

-- 
Mikael Magnusson