Re: [PATCH] Enable further expansion of parameter name by ${!...}

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

Noticed patches related to this in my git stash.  The thread dies out
without an answer to the question of which default behavior to choose.

I'll quote the entire year-old last substantive message for reference.

On Jan 26, 2015,  9:48pm, Bart Schaefer wrote:
} Subject: Re: [PATCH] Enable further expansion of parameter name by ${!...}
}
} On Jan 26,  3:00pm, Tomoki Sekiyama wrote:
} }
} }                     # ksh       bash     zsh(default)       zsh(KSH)
} } echo $aaa           # bbb       bbb      bbb                bbb
} } echo ${!aaa}        # aaa       ccc      bad substitution   bbb
} 
} OK, but the point is that ideally in that last row the zsh(KSH) case
} would be "aaa".  I guess this is no worse than the difference of
} ${array[1]} with or without ksharrays set.  (If "nameref aaa=bbb",
} then the first column of the last row would be "bbb".)
} 
} }                     # ksh       bash     zsh(default)       zsh(KSH)
} } echo ${!foo[bar]}   # foo[bar]  piyo     bad substitution   bar
} 
} I find this one interesting, because the ksh doc says it "expands to the
} name of the subscript" which would seem to me to fit the zsh(KSH) column
} more than the ksh column.
} 
} Ksh also has the special case ${!foo[bar..baz]} which treats the array
} keys as an alphabetical list and generates a sub-list of them from "bar"
} through "baz" (uninteresting in this example).
} 
} } According to this, introducing bash-like behaviors instead of "bad
} } substitution" error will not hurt zsh even in ksh emulation mode.
} 
} My question is, why choose the bash behavior for the zsh default and
} not the ksh behavior?  If we make the bash behavior the default, then
} also adding namerefs as a default leaves us deviating from ksh on the
} meaning of ${!aaa} for identifiers that are not namerefs.


The patch I have (workers/34390) implements the bash behavior as the
default, without changing zsh's incorrect ksh emulation.

Obviously we're nowhere close to adding namerefs, so maybe we should just
punt on this until that happens.