On Sat, 17 Feb 2024 at 02:32, Chet Ramey <chet.ra...@case.edu> wrote:
> Let's say we take the approach of restricting attribute changes on readonly > variables to export/trace/local. > > Should it be an error to attempt to set other attributes (it already is > with nameref), or should declare silently ignore it? > I would prefer to make "local" behave as much as possible like a true lexically scoped declaration in "regular" languages. Much as I hate the effect on backwards compatibility, I hate the current situation even more: it's not possible to write a re-usable general-purpose utility function because the function has to avoid overriding outer variables that might differ in their attributes from what the function needs. Arrays and read-only are particularly problematic. So yes please, I'd like "local" to push a new variable definition that inherits nothing from any outer one: not name-ref, not read-only, not array (of any kind), not assignment modifiers (integer, upper-case, lower-case), and above all, not any previous values. Ideally each function invocation would have its own variable namespace, only using the global namespace as a fall-back, but that creates complications with exported variables, so let's take baby steps to get there. Maybe this would be twisting 'local' too much, and it warrants creating a new keyword such as 'var'? -Martin
