Subject: Re: [PATCH] typeset: set $? on incidental error
From: Daniel Shahaf <[email-masked]>
To: Eric Cook <[email-masked]>
Cc: [email-masked]
Date: Fri, 15 Jan 2016 06:26:45 +0000
List-Id: Zsh Workers List <zsh-workers.zsh.org>

Eric Cook wrote on Thu, Jan 14, 2016 at 00:24:36 -0500:
> On 01/13/2016 07:13 PM, Daniel Shahaf wrote:
> > The 'typeset' family of builtins doesn't set $? when one would expect it
> > to do so:
> > 
> >     % x=$(true) y=$(exit 42); echo $?
> >     42
> >     % local x=$(true) y=$(exit 42); echo $?
> >     0
> > 
> > This patch makes 'typeset' behave as ordiary assignment does.
> 
> 
> But who expects that?

I did.  I ran into this in practice:
.
     https://github.com/zsh-users/zsh-syntax-highlighting/blob/28932316cca6004253ec57f5d87981c72be64e86/tests/test-highlighting.zsh#L118-L121
     118	run_test() {
     119	  # Do not combine the declaration and initialization: «local x="$(false)"» does not set $?.
     120	  local __tests_tempdir
     121	  __tests_tempdir="$(mktemp -d)" && [[ -d $__tests_tempdir ]] || {
.
Having such comments in source code suggests the language semantics are
surprising / non-obvious.

This was also reported to debian years ago (http://bugs.debian.org/479841).

> no other shell with a typeset behaves that way.

So if this change is made, zsh users who switch to other shells might be
surprised that those other shells don't set $? of typeset.  On the other
hand, if we agree that «typeset x=$(exit 42)» should set $?, then
perhaps zsh can be the first to implement that and other shells will
follow.

Somebody has to be the first shell to change behaviour, after all.

Cheers,

Daniel