Re: List of pending patches about named references

[Philippe Altherr <philippe.altherr@xxxxxxxxx>]

> One thing to keep in mind is that removing support for named references to subscripted variables could be as simple as forbidding the definition of such named references.

Following is a quick patch to do just that.

Just a quick fyi: In the meantime I created a patch that removes the support for named references to subscripted variables and all the associated code and tests. There are a few more details I would like to check. I'll try to publish it later today or tomorrow.

Those three patches have now been committed and pushed.

Thanks, that's great news!

 These two have not, because I want to look harder at the necessity in
54047 to introduce another global-scope linked list.

I was wondering the same. One idea would be to piggyback on the global parameter tab. We could have fake variables named "#scoperefs-at-level-<N>" that point to the named references in the scope at level N. The problem is that the parameter table points to a single parameter, not a list of parameters (and we can reuse/abuse the "old" field because it's already used by named references). A list could be stored by adding a new field to "struct param" but that feels overkill to me because that field would only be used in a very tiny fraction of all parameters ever created.

Or could we use multiple fake variables per scope named "#scoperef-<M>-at-level-<N>"? I fear that this would become messy and we would probably also need a fake variable to store the number of references in a given scope.

Other ideas? Are there other global variables we could piggyback on?

Philippe

On Tue, Feb 17, 2026 at 3:02 AM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:

On Tue, Feb 10, 2026 at 7:40 AM Philippe Altherr
<philippe.altherr@xxxxxxxxx> wrote:
>
> One thing to keep in mind is that removing support for named references to subscripted variables could be as simple as forbidding the definition of such named references.

Following is a quick patch to do just that.  Disentangling K01nameref
will require a bit more effort, as it appears on first glance through
the failing tests that some tests that use references also test other
situations that it might be worthwhile to keep testing.

diff --git a/Src/params.c b/Src/params.c
index 3199fd17b..0d71c7f39 100644
--- a/Src/params.c
+++ b/Src/params.c
@@ -6470,6 +6470,7 @@ valid_refname(char *val, int flags)
     ++t;
     }
     if (*t == '[') {
+#ifdef ALLOW_SUBSCRIPT_REFERENCES
     /* Another bit of isident() to emulate */
     tokenize(t = dupstring(t+1));
     while ((t = parse_subscript(t, 0, ']')) && *t++ == Outbrack) {
@@ -6482,6 +6483,9 @@ valid_refname(char *val, int flags)
         /* zwarn("%s: stuff after subscript: %s", val, t); */
         return 0;
     }
+#else
+    return 0;
+#endif
     }
     return !!t;
 }