Re: Parameter flags and subscripts and references

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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.