One possible answer to typeset vs. unset

[Bart Schaefer <schaefer@brasslantern.com>]

Those of you who get zsh repository commit messages will have seen
this already.  Rather than send a patch here (yet), I've taken
Daniel's suggestion and created a new branch.  The changes address the
issue that "typeset foo" creates $foo set to an empty string, by
concealing the internal value rather than altering the way internal
values are defaulted.

You can see these changes by checking out the "declarednull" branch.

I did not (yet) introduce an option or emulation control of this,
though I did test a build where it was predicated on emulation, and
the current default behavior is unchanged in that case.

This imposes the following changes, most of which can be amended if desired:

A typeset variable with no assignment triggers NO_UNSET warnings when
the name is used in parameter expansion or math.  Incidentally, there
is no existing test that covers this; that is, NO_UNSET is tested only
with names that have never been declared or names that have been
explicitly unset.

The typeset -AEFHLRTZailux options are applied upon the first
assignment to the variable. Explicit unset before the first assignment
discards all of those properties. If any option is applied to an
existing name, historic behavior is unchanged.

Consequent to the foregoing, the (t) parameter expansion flag prints
nothing until after the first assignment, and the (i) and (I)
subscript flags also print nothing.  I think the latter is one of the
more problematic consequences, especially for some completion
functions.

One that I forgot in the commit log:  The behavior of "typeset foo;
typeset foo" is changed.  Previously the second typeset would output
the current setting of foo:
  foo=''
With these changes, that outputs nothing.  However, once a value has
been assigned the historic behavior is restored, so "typeset foo=bar;
typeset foo" outputs
  foo=bar
Furthermore, "typeset foo; typeset -p foo" outputs only
  typeset foo

The bash behavior of "unset foo; typeset -p foo" is NOT used.  This is
called out as an emulation distinction, not a change.

The test cases have not been updated, so several now fail.  The test
harness has been updated to declare default values, because otherwise
the harness itself is the first thing that breaks.