From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 22c3a1fc for ; Sun, 22 Dec 2019 03:11:08 +0000 (UTC) Received: (qmail 26604 invoked by alias); 22 Dec 2019 03:11:00 -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: List-Unsubscribe: X-Seq: 45126 Received: (qmail 9244 invoked by uid 1010); 22 Dec 2019 03:11:00 -0000 X-Qmail-Scanner-Diagnostics: from wout2-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.1/25663. spamassassin: 3.4.2. Clear:RC:0(64.147.123.25):SA:0(-2.6/5.0):. Processed in 4.936023 secs); 22 Dec 2019 03:11:00 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdduiedghedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggugfgjfgesth ektddttderjeenucfhrhhomhepffgrnhhivghlucfuhhgrhhgrfhcuoegurdhssegurghn ihgvlhdrshhhrghhrghfrdhnrghmvgeqnecukfhppeejledrudektddrheejrdduudelne curfgrrhgrmhepmhgrihhlfhhrohhmpegurdhssegurghnihgvlhdrshhhrghhrghfrdhn rghmvgenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Date: Sun, 22 Dec 2019 03:10:13 +0000 From: Daniel Shahaf To: zsh-workers@zsh.org Subject: Re: [PATCH 1/2] zshmisc(1): Clarify the documentation of 'return' and 'exit' in conjunction with try/always Message-ID: <20191222031013.kv56dcfq6ypjcoku@tarpaulin.shahaf.local2> References: <20191221124104.22751-1-danielsh@apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Peter Stephenson wrote on Sat, Dec 21, 2019 at 17:58:35 +0000: > On Sat, 2019-12-21 at 12:41 +0000, Daniel Shahaf wrote: > > Having reviewed 20076, 20084, 21734, and 21735, my understanding is that > > the original intention was: > > > > - A 'return' in a function does run always-list > > - An 'exit' outside a function does not run always-list > > - A 'return' outside a function is treated as an 'exit' > > > > All of which are the case today. The remaining case, of 'exit' used > > inside a function, was not specified by the referenced -workers@ posts; > > does, as implemented, run the always-list; and furthermore, based in > > 21734 it's fair to assume that the original documentation was assuming > > that 'exit' would be used outside of any function, just like it assumed > > 'return' would be used inside a function. > > > > Therefore, have the documentation specify only the behaviour of 'exit' > > outside any function, and leave the behaviour of 'exit' inside > > a function unspecified. Anyone who relied on the documentation of 'exit' > > as documented until this commit would have run into the > > documentation/implementation discrepancy described in 45075. > > That seems fine. > > I don't think it would be problematic to document the current behaviour > of exit in a functoin, actually, with the implication it won't suddenly > change as I can't see why it would, The documentation promised one thing and the implementation did another thing. We can't _both_ deliver compatibility and deliver on the API promise, and I didn't want to choose one over the other. I certainly don't intend to change the implementation just because the documentation said so — there's no reason to break people's code. On the other hand, I also want to reinforce the notion that API promises can be relied on. > but leaving the implicit assumption that return is the standard way to get > out of a function and otherwise you're in uncharted territory seems fine, > too. Yeah, it's not ideal, but using exit in a try block in a function _already is_ uncharted territory, so it seems like the lesser of three evils. Thanks for the review, Daniel