/Zsh/Ksh/. Perhaps the Korn developers should have created a new
assignment operator or even a new substitution syntax to make namerefs
distinct from other parameters at all points where they are used.
Totally agree. That's the original sin. If they had done that, this whole discussion would be moot.
Anyway, comparisons of shell with C don't move me a lot.
Sure, my point was just to expose the two kinds of assignments involved.
However, I'm open to discussion of a "no reference name" error on $placeholder.
Yes, let's report a "no reference name" error.
In principle, I don't think that it's inherently wrong to allow expansions of placeholder references. It's the same as allowing expansions of not yet initialized scalars, integers, etc. In practice, it's certainly possible to find cases where expanding placeholder references would be handy but I suspect that most expansions of placeholder references would in fact be the result of a failed initialization of the reference. Therefore, I think that overall we would bring much more value to Zsh users by reporting an error whenever a placeholder reference is expanded.
> while ( ... ); do {
> var=0; # Reset "var" to it's default value
> ...
> }
>
> You can do the same for strings, floats, and arrays. You just have to
> use the appropriate default value. However, for references, that is
> currently not possible.
I don't see how it would ever be possible?
See the original thread for an explanation of how "<null>" would allow that. It would be a nice extra benefit of a new syntax but it's certainly not something that we absolutely need.
> It is detrimental because it implies that a statement like "typeset -nu ref=$1"
> will not necessarily initialize the reference. Innumerable users will have to
> figure out why their script exhibits a completely weird behavior
Would "no reference name" on dereference mitigate this?
Definitely yes. Functions that only expand "ref" would then consistently fail. Unfortunately functions that only assign to "ref" or first assign to "ref" would still produce very weird behavior. That's why I would still consider "" as the default value as too problematic.
> > It is detrimental because it implies that a statement like "typeset -nu ref=$1"
> > will not necessarily initialize the reference. Innumerable users will have to
> > figure out why their script exhibits a completely weird behavior
(In my estimation, these users will be quite numerable, or at least
not more innumerable than before).
My point was that among the following two sets of users, the first one will be orders of magnitudes larger than the second one. Furthermore, I suspect that only more astute users will ever notice the discrepancy. Those are also likely to be ones that are able to figure out a workaround in case they need one. Therefore, I would rather have no default value for references than the empty string (but there are other options, see the original thread).
A) Set of users that will have to spend time debugging cases where "typeset -nu ref=$1" leads to a weird behavior because "$1" erroneously contained an empty string and no error was reported by "typeset" because the empty string is the default value for references.
B) Set of users that complain about the fact that or just notice that references, unlike other types of variables, don't have a default value.
Philippe