Re: Parameter flags and subscripts and references

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On Mon, Nov 17, 2025 at 4:42 AM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> On Sun, Nov 16, 2025 at 5:40 PM Philippe Altherr
> <philippe.altherr@xxxxxxxxx> wrote:
> >>
> >> $r2 is implicitly doing ${(!)r1[2]} because of the "stop at
> >> subscripts" behavior.  This could at least be documented (note to
> >> self).
> >
> > This looks wrong to me. In my opinion "print $r2" should return the same as "print ${r1[2]}".
>
> Well, yes, that would be ideal ... documentation would be the fallback.
>
> >> Maybe the answer is that ${parameters[foo]} should *never* expand to
> >> "nameref-scalar" and should just stop at "nameref" like (t!) does,
> >> regardless of what "foo" represents.
> >
> > I wouldn't change anything right now. Indeed, if we can eliminate "stop at subscripts", the current behavior might become consistent but if "stop at subscripts" remains in place, your proposal might be the better alternative.
>
> In hindsight it was probably not the best idea to allow the
> subscripted references in the first place.  I was seduced by symmetry
> with ${(P)...} but as with (t), named references are really meant to
> be defined on parameters, and as soon as a subscript is introduced the
> result has changed from a parameter to a value.
>
> It may be possible to resolve that conundrum in fetchvalue() but I see
> no way to do so in getpmparameter() (i.e. $parameters) without
> unwanted evaluation side-effects.

We could still change this, couldn't we? Unless I'm mistaken, namerefs
still aren't in any released version of zsh.

-- 
Mikael Magnusson