From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1001 invoked by alias); 22 Jan 2017 18:45:58 -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: 40394 Received: (qmail 19286 invoked from network); 22 Jan 2017 18:45:58 -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 0.748265 secs); 22 Jan 2017 18:45:58 -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: Sun, 22 Jan 2017 10:45:21 -0800 (PST) From: Bart Schaefer Reply-To: Bart Schaefer To: zsh-workers@zsh.org Subject: Re: LOCAL_VARS option ? In-Reply-To: <20170120171922.0e0c370d@pwslap01u.europe.root.pri> Message-ID: References: <20170119065408.GA5534@fujitsu.shahaf.local2> <20170119160841.354ec75c@pwslap01u.europe.root.pri> <20170120171922.0e0c370d@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 Fri, 20 Jan 2017, Peter Stephenson wrote: > Here's a first go at the warning option, with "functions -W" to turn it on > in the same fashion as "functions -T". The option is called > WARN_NESTED_VAR for now. This is almost exactly what I was thinking ... except I wasn't thinking of it having a name that could be accessed with setopt. I was thinking more of something that could ONLY be activated by "functions -W". Still, I can see it either way, so thanks for the prototype. > The main drawback over WARN_CREATE_GLOBAL is that "typeset -g" doesn't > mark the variable for future assignments; it's still in a global scope > so still gets a warning next time. I think that's correct behaviour It certainly seems reasonable. Possible logical extensions would be to warn only if the variable is truly in global scope, or to warn only if the variable is NOT in global scope (i.e., is local to some caller's scope). If -W were implemented in some other way than as a setopt, it could accept arguments (along the lines of gcc -W...) to indicate different kinds of warnings.