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:
>
> Next, I think all the instances in which PM_UNSET is checked should be
> verified, to see if PM_DECLAREDNULL makes sense in those. I'll do
> that.

In cases I've discovered so far, it's actually more likely that one
has to check whether PM_UNSET and PM_DECLARED are boolean different,
rather than whether both are (not) set.

> Next, we need a way to make sure $empty[(i|I)] returns something
> sensible (that would be for both approaches).

That's the last thing on my list, too.

> And I think that's it. All that's left is deciding what flag would
> turn this mode on.

I'm leaning toward POSIXBUILTINS.

> Lastly, I don't know if there is any low-hanging fruit, for example;
> doing the same as bash 5.0 with localvar_inherit and localvar_unset.

I thoroughly dislike localvar_inherit.  I wonder if it's in bash 5.0
just to be able to compare the suggested semantics from that rejected
POSIX proposal we've previously discussed.  I may be biased by long
use of the zsh semantic, but treating global -> local like environ ->
global seems weird, unless there's also a way to "export" a local back
to global.

> I don't quite get localvar_unset, but seems to also be a sensible default.

If I'm reading the bash manual correctly, localvar_unset means that
"unset foo" behaves like "local foo; unset foo".  Thus (Chet will
probably correct me):

fn1() {
  unset foo
}
fn2() {
  local foo=something
  fn1
  echo ${foo-nil} # is nil
}
fn3() {
  local foo=something
  shopt localvar_unset
  fn1
  echo ${foo-nil} # is something
}