Re: RFC: Nested enclosing returns

From: Date: Sun, 22 Mar 2015 09:06:43 +0000
Subject: Re: RFC: Nested enclosing returns
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-85403@lists.php.net to get a copy of this message
Am 21.03.2015 14:15 schrieb "Georges.L" <contact@geolim4.com>: > > The main purpose, as the title say, is to have the possibility to nest > multiple return like we can do currently with break/continue. I think that is a complete nonstarter. Functions are reusable building blocks, designed to be called from various places that the function author should not be concerned with. break/continue can always be analyzed at the single function level, with semantics unambiguously given by the local nesting level within the function. On the other hand, functions being called from various places means the nesting distance between a given point in the outer program, and the function itself, is completely arbitrary for different calls. In some places in our codebase we have logging functions that try to show "logically useful" debug_backtraces, by leaving out a number of "lowest" levels of the stack. Starting down that road soon required us to introduce "$up = 2" parameters to the inner logging functions, so that different call pathes could impose how much to leave out (think some convenience wrappers). This is a very brittle thing to do. Okay for debug backtrace logging, because at worst it shows some unneccessary level or leaves out some. But totally unmanageable when it affects really control flow. I know exactly one language that provides similar stuff - TCL with its uplevel and upvar constructs - and anybody who had to wrap their heads around code using that, nifty as it can be, will know the cognitive strain involved... Patrick

« previous php.internals (#85403) next »