Re: Warning about failed assignments to references to not yet defined variables

I'm fine if upper references to not-yet-defined variables aren't supported but I would very much prefer that this triggers an error rather than does something not defined. In my opinion undefined behaviors in programming languages are lazy and don't help anyone, neither the language users nor the language implementers. Users may (more often than not inadvertently) write code that relies on undefined behavior. That code is then at the risk of breaking after a language update. Implementers are at the risk of inadvertently changing the undefined behavior and thus break the code of all users who started relying on it.

Here, signaling an error when an upper reference is initialized with a not-yet-defined variable would be easy. Why not do it?

Philippe

On Tue, May 27, 2025 at 6:46 AM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:

On Wed, May 21, 2025 at 1:39 AM Philippe Altherr
<philippe.altherr@xxxxxxxxx> wrote:
>
> function () {
> typeset -nu ref=var
> typeset var=inner
> ref=outer
> echo ref=$ref
> }
> typeset -p var
>
> The assignment ref=outer is supposed to create a global variable named var but it can't because there is a local variable with the same name. Shouldn't this print a warning?

I'm still going to reply further to this on the other thread, probably
tomorrow, but the documentation specifically mentions that your
example is probably wrong:

To force a named reference to refer to the outer scope, even if a local
has already been declared, add the -u option when declaring the named
reference. In this case RNAME should already exist in the outer scope
before PNAME is initialized, otherwise the behavior of assignment
through PNAME is not defined and may change the scope of the reference
or fail with a status of 1.

Note "In this case RNAME should already exist in the outer scope." If
you test the result of the ref=outer assignment, you'll see $? == 1.
Behavior is explicitly not defined.