From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20961 invoked by alias); 20 Jan 2017 05:02:21 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 40389 Received: (qmail 7796 invoked from network); 20 Jan 2017 05:02:21 -0000 X-Qmail-Scanner-Diagnostics: from mercury.zanshin.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(64.84.47.142):SA:0(-0.0/5.0):. Processed in 1.844551 secs); 20 Jan 2017 05:02:21 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at ipost.com designates 64.84.47.142 as permitted sender) Date: Thu, 19 Jan 2017 21:01:41 -0800 (PST) From: Bart Schaefer Reply-To: Bart Schaefer To: zsh-workers@zsh.org Subject: Re: LOCAL_VARS option ? In-Reply-To: <20170119160841.354ec75c@pwslap01u.europe.root.pri> Message-ID: References: <20170119065408.GA5534@fujitsu.shahaf.local2> <20170119160841.354ec75c@pwslap01u.europe.root.pri> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) X-Face: "f/X=UCVgd*^c>+x(gMq0at?e:woX+;'snkkRzc3SX<0AZ (/PS4.M2hzGS9X:Qj]at_H/%a9K}:-eS<"v_7vX84PG9Bf Zpb`wI!I4geY=or+nWq`3CX`oq&TJR;g^ps|7(MH?jh;bs %vHJfCh5>a*6Re5m|Bidja\\o]>n\A)ib1:yX*T`zR(*h~ %tOw<~!D9{e6h!8M2:d8G2@K>y^1I_Vdy\d\MYe]z7c MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 19 Jan 2017, Peter Stephenson wrote: > On Thu, 19 Jan 2017 07:47:53 -0800 > Bart Schaefer wrote: > > 2. Unlike local_options, which applies when the function exits, this has > > to be applied when the parameter is created. There's already a > > mechanism to accomplish this, namely to declare the parameter. The > > only reason to need local_vars is to change the semantics of *other* > > functions [see (1)], which is generally a bad idea. > > Hmmm... I suspect people would want to set it to protect their own > functions That's what zsh/param/private is for ... > > 5. (New since the last time this was discussed) The type of problem this > > "solves" is generally better addressed by WARN_CREATE_GLOBAL so that > > proper use of parameter declarations can be applied. > > Yes, that makes a difference, but it doesn't detect the case where you > re-use a variable in a nested function without redeclaring it. (That > can be done, too, by comparing variable levels, but it's a significantly > more intrusive option --- consider the completion system.) Perhaps rather than a setopt, this could be a property of functions -- something like "typeset -fT" so limited to the single function to which it is applied. That could be appropriate either for a generic "used but not declared local" warning or the "implicit local var" feature, though I would still have reservations about the latter. Anyway the point is that we should make it easier to debug these issues rather than make it easier to sweep them under the proverbial rug.