On Tue, 26 Aug 2025 at 00:28, Chet Ramey <chet.ra...@case.edu> wrote:
> On 8/23/25 11:40 PM, Martin D Kealey wrote:
> > In other languages, binding and assignment are clearly different
> > operations, where this would clearly NOT be "no different".
>
> Oh?
>
> int x = 0;
>
If we're talking about C, that's initialisation, not binding. C doesn't
have binding in the sense that "declare -n" means.
Examples from languages that do have binding (and which is obviously
different from assignment).
In Perl:
*Foo = \$Bar;
vs
$Foo = $Bar;
In C++:
int &x = y; /* or equivalently: int &x (y); */
vs
int x = y;
> In respect of -l, -u and -r, that's fair comment, so let's set those
> aside
> > and focus on binding with -i, where the old behaviour was to fail
> silently.
>
> Why would you ignore -i […]
Or are you only considering the -in case,
If you are, then make your reasoning explicit.
>
Considering that I'm specifically distinguishing "binding" and
"assignment", I thought it was already explicit.
Perhaps I should have used a different term rather than "binding", or
explained it using an illustration from another language (as above).
> Ignoring -i when binding (only applying it when assigning) would seem
> like
> > a reasonable backwards-compatible extension,
>
> Maybe you could give an example of what you mean.
>
$ bar=11**2
$ declare -in foo=bar # binds to bar, not to 121 (which it currently fails
to do)
$ echo "$bar"
11**2
$ echo "$foo" # not magic when reading, though I'm open to changing this
too
11**2
$ foo=$foo # numeric evaluation, since foo has -i
$ echo "$bar"
121
$ foo+=$foo
$ echo $bar
242
$ bar+=$bar # string concatenation, since bar lacks -i
$ echo $bar
242242
$
The point is to avoid changing the flags on bar, because that's the less
surprising behaviour when foo is local to a function and bar is not:
$ square() {
local -in v
for v do
v=v*v
done
}
$ x=4 y=$x
$ square y
$ y="$x² = $y" # would be broken if y acquired -i
$ echo "$y"
4² = 16
$
Hope that's clearer
-Martin
