Bash feature request: provide state data pointer and unset_func for dynamic variables

[tetsujin]

Hi, I think this is probably kind of an unusual request, but you don't
get anything you don't ask for, right? So I figure it's worth a shot.

Basically, I am working on a library called shell-pepper (it's not too
far along at this point) - the general concept is that it's like a
grab-bag of functionality I'd like to have in the shell, implemented
as loadable "builtins" (when necessary), shell functions, and ordinary
executables. My ultimate aim is to provide some useful functionality
in fairly consistent ways across a few different shell
implementations, and maybe also serve as a useful example of how to
write non-trivial shell builtins.

I was hoping to use the "dynamic variable" mechanism as the basis for
a rudimentary "object" system. The main benefit of such a system would
be some degree of automated control over the lifetime of these
"objects" - in particular, they can be tied to the lifetime of "local"
variables within a function, or used to trigger actions when a script
terminates - basic RAII type stuff.

My goal with this functionality in the library is to use it as a
starting point to extend the shell in non-invasive ways, use variable
lifetimes to control subprocess lifetimes, that sort of thing.
Obviously asking for a code change in one of the shells I plan to
support is pretty "invasive"...  But in this case it's the only way I
can come up with to provide this kind of functionality.

So there's basically these two fundamental limitations in Bash
variables that prevent this plan from working:

1: Variables can't really carry data other than what's in
SHELL_VAR.name, .value, and .exportstr, and those already have defined
meanings. Even in the case of dynamic variables, the dynamic_value()
function is expected to populate SHELL_VAR.value (at least, that's my
understanding), so the options for storing object data in a variable
are rather limited. (Best I could come up with, is store some data in
.value after the end-of-string marker. But that could be problematic,
too, if some piece of code somewhere assumes that .value ends with
that null byte...  copy_variable() does this but as far as I can tell
it's not called. So it could work, it just seems a bit risky..)

2: The dynamic variable implementation receives no notification when
the variable binding is destroyed (as with unset, or end-of-scope for
a local variable, etc.) - this means the implementation backing a
dynamic variable has no way of knowing when data associated with a
dynamic variable is no longer needed. For the dynamic variables
implemented in the shell this isn't a significant issue (because they
use global variables for their state, and don't support multiple
instances - they are implementations of dynamic variables, not
implementations of *classes* of dynamic variables.) but for my
purposes, in which I would ultimately have commands that create
dynamic variables, it's a problem.

So the code change would go something like this:
- Add a new pointer field in "struct variable", "void *state_data" or
some such. The pointer is initialized to zero when a variable is
created, and otherwise the value of the pointer and the
allocation/deallocation of the data it points to is the responsibility
of the dynamic variable implementation associated with the variable.
- Add a new function pointer field in "struct variable", called
"unset_func". If the function pointer is nonzero, then it is called as
a function (with the variable struct as an argument) prior to
destroying a variable binding.

Offhand, I can anticipate a few potential down-sides to this idea:
- Increasing the memory footprint of all variables by two pointers
(whether they're dynamic variables or not)
- Potentially breaking existing third-party loadable "builtin" code by
changing the variable structure
- Introducing maintenance burden for a feature that is not presently
needed for Bash itself

Anyway, I thought I'd float the idea and see if it might be a
possibility.