Re: uninvited members of associative array

[Ray Andrews <rayandrews@eastlink.ca>]

On 2022-12-17 14:10, Bart Schaefer wrote:
> The input doesn't have a type. It's the result of a substitution, so
> it's just a series of separate words.  Where the words came from is
> not remembered.  Consider:
I suppose it could be looked at that way, OTOH it could be that the type 
is referenced.  After all the type *is* recorded.  typeset -p doesn't 
just cough up the contents, it knows that an AA should display 
differently than a normal array.  Since the type information is there, 
there's no reason why it might not be referred to.
>
> set -A thing new1 new2 "${(@kv)whatever}" new3 new4
>
> What "type" is that?	set -A IN "${(@Pkv)${1}}" # Copy the array to IN, the working copy.
>
Not fair.  In that case 'thing' is not assigned any type, so it's 
defaulting to a normal array is unavoidable.   But if I do:

set -A IN "${(@Pkv)${1}}"

.. and $1 names an array that typedef knows is an AA, then it wouldn't 
be very much work for IN to be matched with that type. It would avoid 
the gotcha that lead to my question.  Mind, as usual, once one is 
forewarned of the issue it's not hard to deal with.  As I mentioned, my 
case would rely on the precedent that that's the way it is with integer 
promotion.  Good thing too, because doing arithmetic on a scalar is 
slightly absurd.

Note the importance even then of knowing the type being assigned-to, 
which is
> exactly why you have to declare it before calling "set -A".

Well it's simple and hopefully failsafe, but I still  can't help but 
thinking that if typedef knows the type of the input then the type of 
the output could be assigned as well as the values.

Daniel:

> Could someone please clarify this in the manual? 

Thanks.  It makes me feel less stupid when someone agrees with me that the manual isn't as clear as it could be. The manual was written by someone too intelligent for the job -- no empathy for the less gifted.

>