From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11159 invoked by alias); 19 Jan 2017 15:48:42 -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: 40387 Received: (qmail 16550 invoked from network); 19 Jan 2017 15:48:42 -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 2.293701 secs); 19 Jan 2017 15:48:42 -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 07:47:53 -0800 (PST) From: Bart Schaefer Reply-To: Bart Schaefer To: Daniel Shahaf cc: zsh-workers@zsh.org Subject: Re: LOCAL_VARS option ? In-Reply-To: <20170119065408.GA5534@fujitsu.shahaf.local2> Message-ID: References: <20170119065408.GA5534@fujitsu.shahaf.local2> 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, Daniel Shahaf wrote: > Phil suggested on IRC a LOCAL_VARS option that has the effect of making > all newly-declared variables local; e.g., > > % unset x y > % () { setopt localvars; x=42; typeset -g y=43 } > % echo $+x $+y > 0 1 > % > > I'm attaching a proof of concept patch (work in progress; see top of the > attachment for known issues), but WDYT of the the general concept? I believe we discussed this idea once before, and rejected it on several grounds. However, I can't find the thread at the moment. From memory: 1. Once the option is set, it affects all functions called by (whether directly or indirectly) the one that set the option. If set at the top level, this results in a significant change in semantics. 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. 3. If unset by a called function in order to prevent (2) and that called function is NOT also using local_options, it can break the calling function in unpredictable ways. 4. The semantics of the other LOCAL_* options are already problematic in obscure ways, but just because we're stuck with them doesn't mean we should add another potentially problematic variation. 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.