Re: One possible answer to typeset vs. unset

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Fri, Dec 4, 2020 at 3:04 AM Felipe Contreras
<felipe.contreras@xxxxxxxxx> wrote:
>
> On Thu, Dec 3, 2020 at 3:19 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> >
> > I looked at this for a while yesterday evening.  My conclusion is that
> > tied variables are already a bit of a hack.

Part of my latest commit log on the declarednull branch:

The scalar struct param of a tied pair stores a direct pointer to the
internal array value of the array struct param, and upon assignment
modifies it without referring to the containing struct. This means
that there's no opportunity to clear the PM_DECLAREDNULL bits on both
structs when the scalar is assigned. Conversely, assigning to the
array does use the struct for the scalar.

I think this can be fixed but I don't want it to become inefficient.
OTOH, tied parameters (other than specials, which are different in
several ways) may not be used (or updated when they are) very much.

> > Consequently I don't know if your patch would cause a different test
> > for unset-ness (that hasn't been written yet) to fail, but something
> > like that patch may be unavoidable.
>
> I can't parse that. What would such unset-ness test do?

Check that both elements of the pair appear to be unset when neither
has been initialized.

As it currently stands on the branch, following

typeset -T TIED_SCALAR tied_array

These

typeset -p TIED_SCALAR
typeset -p tied_array

print differing initializers.