Re: BUG: Initializations of named references with an empty string should trigger an error

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mon, Jun 9, 2025 at 7:44 AM Philippe Altherr
<philippe.altherr@xxxxxxxxx> wrote:
>>
>> I was going to demonstrate, but instead I just demonstrated what I
>> think may be a bug.
>>
>> typeset -n ref=var
>> typeset -n ref
>
> I don't think that this is a bug.

That is neither a bug nor is it the bug to which I referred.

> So there is definitely a bug. I guess that both should work like the first one, which is also what happens for "-i" variables.
>
>> [...]  if others feel as strongly
>> as Philippe does about declaring empty-value namerefs, then I suggest
>> we use "." (dot) instead of something like "<null>".
>
> In principle, the syntax "." is still wrong because it's a valid string. It can still show up in the "$1" of a "typeset -nu ref=$1" where in principle it should be seen as an invalid variable name

The problem with BOTH "." and "<null>" is they're strings, not actual
out-of-band values (which I repeat were discussed and rejected).  What
is
   foo="<null>"
   typeset -n foo
supposed to do?

I suggested "." because ${.} is a simple substitution error and
doesn't involve inventing new tokenizations of any existing operators.
Unlike ${ cmd } there is no tokenizer/parser magic about namerefs and
I feel very strongly that it should stay that way.

> A middle ground between "." and a new syntax like "<null>" would be to reuse the syntax "()".

That only works for the reserved word version of typeset.  It would be
a syntax error for the builtin, which means it breaks for zsh/ksh93
module nameref command (which actually is probably OK because ksh
doesn't have a way to reset a nameref to default anyway).  There's no
universal assignment that always works.

> ** I have just noticed that currently "typeset -n ref=(aa bb cc)" generates a "typeset -an ref=( aa bb cc )". I guess that's a bug. It should report an "inconsistent type for assignment" error, right?

It was intended to be caught here:

% typeset -an ref=( aa bb cc )
typeset: -a not allowed with -n

I overlooked that using the paren syntax skips past setting the -a
option.  Patch later.

>> It's becoming unhelpful for just Philippe and I to keep batting these
>> points back and forth, it's not building any kind of consensus.
>
> Indeed, it would be good if a few others also chimed in.

This discussion has usefully exposed some bugs but my feeling for a
while is that we're diving too deeply into edge cases and imagined
usages before having any real-world experience with the feature.  Has
anyone actually seen a significant ksh script that employs namerefs?