Re: Should defining a reference to an autoload parameter load it?

[Philippe Altherr <philippe.altherr@xxxxxxxxx>]

Oh, interesting, I didn't know that specials couldn't be hidden without the -h option.

Is it expected that the following doesn't trigger an error?

zmodload -u zsh/random
() {
  typeset SRANDOM=foo
  echo $SRANDOM
}

Output:

foo

Apparently, for nested variables, the read-only error is only triggered if the special was previously loaded. If you do the same at the top-level or add an "echo $SRANDOM" before the "typeset", then you get the error.

Regarding reference definitions, do you have any preference about whether they should trigger loading? If not, I will go for NOT loading (which I think also leads to simpler code; no getparamnode_nofollow needed).

Philippe

On Tue, Jun 10, 2025 at 9:17 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:

On Tue, Jun 10, 2025 at 11:24 AM Philippe Altherr
<philippe.altherr@xxxxxxxxx> wrote:
>
> Here is an example that will behave differently depending on whether loading happens or not at definition time:
>
> () {
>   typeset -n ref=SRANDOM[1,20];
>   typeset SRANDOM=local-variable
>   echo $ref
> }

This is one of the things that the upscope() your patches removed from
createparam() was checking for:  a special hidden by a local.  (Might
nevertheless have had some of the edge cases wrong.)  If loading
happens (or if the named reference declaration is omitted), you should
see this:

(anon):2: read-only variable: SRANDOM

because the default for locals with the same name as specials is to
retain the special behavior.  This is currently broken with your
patches applied, including the explicit case:

   local +h SRANDOM

This is avoided by

  local -h SRANDOM

in which event your analysis about named reference dereferencing does apply.