Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Parameter flags and subscripts and references



In hindsight it was probably not the best idea to allow the
subscripted references in the first place.

To be honest, when I read in the documentation that subscripted references are supported, I thought that it was a little crazy but I also recognized that it was an awesome feature, if it worked. Unfortunately, from what I have seen, it's way too easy to stumble on cases where it doesn't work. I will eventually write a report on all the shortcomings that I have found.

I was seduced by symmetry with ${(P)...} 

Implementation-wise, ${(P)...} has the advantage that the referent always appears within a ${...} which eases a lot of things (with the current implementation). With named references that's not the case and thus there are cases where ${ref} returns the right value but $ref doesn't. That's just one of the issues with subscripted references.

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.

I don't think that it's inherently wrong/impossible to allow subscripted references but fully supporting them with the current implementation without major refactorings seems impossible to me.

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

I was reluctant to propose the following because I feared that it would be very controversial but maybe it's not after all.

From what I have seen, subscripted references suffer from many shortcomings. I got the impression that some could maybe be addressed with small code changes (but I don't have any working code so I could also be very wrong). However, it looks impossible to me to address all of the shortcomings without major refactorings. Maybe we could document and/or forbid some of them but my feeling is that we could never deliver robust support for subscripted references; users would constantly stumble on shortcomings as soon as they try to do slightly more involved things.

For these reasons I came to believe that the best course of action would be to only allow references to plain parameters for now. I still think that subscripted references would be awesome but I would look into supporting them only in a subsequent release. This would give us time to implement the major refactorings that would be required.

Philippe



On Mon, Nov 17, 2025 at 10:17 AM Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
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


Messages sorted by: Reverse Date, Date, Thread, Author