Re: [PATCH] declarednull: rename DECLARED to NULL

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sun, Jan 3, 2021 at 10:17 PM Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
>
> Could you summarize the bits that need to be named and the corresponding shell
> language incantations/semantics?

There has been a series of threads about this, but to try to summarize:

In current zsh,
  typeset -i var
  typeset -p var
  print ${var-foo}
produces the output
  typeset -i var=0
  0

Note that integer declaration (-i) is for example purposes only
(because then $var is visibly zero rather than empty string); the
flags to typeset don't matter, only the fact that there is no
assignment in the command is significant.

This disagrees with e.g. bash/ksh, so the proposal is that with
POSIXBUILTINS set, the same three commands would output
  typeset -i var
  foo

That is, even though a parameter named "var" has been declared, and
that declaration can be regurgitated, "dereferencing" $var produces a
result equivalent to examining a variable that is unset.  Felipe has
argued that this is functionally equivalent to having assigned a NULL
value to the name "var".  Internally, zsh does not have a
representation for a NULL value (although with a number of changes, it
could do so for non-numeric types where the parameter union contains a
pointer, and we spent a while discussing whether those were the only
cases that require implementation).

My approach has been to create an additional flag (originally called
PM_DECLARED) which represents the state immediately following
  typeset -i var
and then to bitwise-OR that with PM_UNSET to minimize differences in
code that tests for unset-ness.

So the "bits that need to be named" are:
1) the bit representing "remember that this was declared but no value
was assigned"
2) the combination of that with PM_UNSET that represents "functionally
behaves like NULL"

We could of course simply never name #2 and always write out the
bitwise-OR, but that seems cumbersome.

As I understand it, the objection to PM_DECLARED for #1 is that the
name implies that only "unset var" should ever turn that bit off
again, but the implementation requires that assignment also turns it
off.  Similar objections of English language semantics conflicting
with the implementation have been raised to other names I've
suggested.

> Is this anything like using «struct foo **p» in C to denote a single parameter
> that has three possible states

Sort of, except that (!p && *p) is actually "valid".  The problem is
that ${var-foo} resolves as if (!p) but ${var} resolves as if *p=""