Namespaces (was Re: Remove support for named references to subscripted variables)

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Wed, Feb 18, 2026 at 4:33 PM Philippe Altherr
<philippe.altherr@xxxxxxxxx> wrote:
>
> Given the description of namespaces in section 15.1, I'm surprised that ".foo" and "foo." are valid. I would have expected that names with namespaces must always contain two non-empty identifiers.

From Test/K02:

  .k=OK
  print ${.k}
0:Bare namespace is usable (ksh compatibility)
>OK

  k.=empty
  k.2=test
  print ${k.} ${k.2}
0:Parse without leading dot (future proofing)
>empty test

This was all explained in the zsh-workers postings during the
development of namespaces, but the documentation discusses only the
parts that are guaranteed not to change in the future.

> I'm also a little surprised that the second identifier may start with a digit. I'll admit that there is nothing in the documentation that forbids it. It's just because identifiers usually have to start with a letter.

  .not.2b=question
1:Identifier starting with a digit must be all digits, assignment
?(eval):1: not an identifier: .not.2b

The name following a namespace prefix has to fit the rules of a name
that does NOT have a namespace prefix.  This is because a future
extension might introduce namespace scopes, e.g., the ksh-ish
construct

namespace foo {
   echo In this block, $id is the same as ${.foo.id}
}

Since zsh allows assignment to positional parameters, the thought is
that one should be able to have "positional" names in a namespaces
(even though ksh does not).

> Finally, I'm more than a little surprised that "foo", ".foo" and "foo." are all valid but not ".foo.". Same for "foo.456", ".foo.456", and "foo.4ar", which are all valid but not ".foo.4ar".

foo.4ar should not be, but the "future proofing" parse mentioned in
the test case isn't following the full set of rules.  Could probably
be tightened up.