Re: Named reference (and other) pending work
Bart Schaefer <[email protected]>
| Newsgroups | gmane.comp.shells.zsh.devel |
|---|---|
| Message-ID | <CAH+w=7ZpUyRs9pMWQ=gV=menUxu9t0LsvJv19d9HsmUtKQSAog@mail.gmail.com> |
On Sun, May 3, 2026 at 1:22 AM Philippe Altherr <[email protected]> wrote: >> >> > In ksh, any attempt to dereference a placeholder reference triggers an error. Zsh should do the same. >> >> I disagree (except in ksh emulation mode). > > So should there be a check for ksh emulation mode? Rather, I meant that I would not disagree in ksh emulation mode ... but there are a lot of places where we're not faithful to ksh emulation (consider any of several other expansions, or look at the doc for the ksh93 module) so I don't think it's especially important to follow that here either. > One example of dubious behavior is if you try to unset (with no -n) a placeholder reference or a chain to a placeholder reference. This should unset the referred variable but since there is no such variable the current code unsets the placeholder reference. I think that in this case it would make more sense to complain Hm, I agree that it likely shouldn't unset the reference, but I'm undecided about the complaint -- `unset this_was_never_set` doesn't complain. On the other hand unset ${(!)placeholder} would complain about not enough arguments. I could go either way. > Similarly, if you use typeset -i var to change the type of var and it turns out that var refers to a placeholder reference, it tries to change the type of the placeholder reference (which triggers an incompatible type change error) while it would make more sense to complain that there is no referred variable. I agree that the error could be more specific. The case where 'var' is a nameref pointing to something that doesn't exist already creates the referent, the same way an assignment would, with PM_DECLARED or a default value depending on typeset_to_unset, so that's fine.