Re: RFC: Nested enclosing returns

On Sat, Mar 21, 2015 at 1:13 PM, Georges.L <contact@geolim4.com> wrote: > Hi php internals, > > After some long and deep research i finally decided to write my first RFC > about a feature i'd be interested to be improved in the php core: *Nested > enclosing returns* > > > 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 thinks it'll being better with a scheme: > > > > > function foo($foo = true) > { > if(!$foo) > { > return false, 3;// Please note the second return argument is the > return nesting level > } > else > { > return true;// Default nested return argument is always equal to > 1 (if not specified, current) > } > } > > function bar($foo = true) > { > foo($foo); > // Some stuff that will never be executed if $foo == false and > nested return argument = 2 > echo 'Hi jon !'; > } > > function baz($foo = true) > { > echo 'Hi bertie !'; > foo($foo); > // Some stuff that will never be executed if $foo == false and > nested return argument = 3 > echo 'Hi freddy !'; > } > > > baz(true); // Display: > // Hi bertie ! > // Hi jon ! > // Hi freddy ! > > baz(false); // Display: > // Hi bertie ! > > > Benefits: > -Wont break compatibility > -May improve code interpretation speed due to part of code skipped by the > nested return. > -Allow "dynamic" return expressions. > > Inconveniences: > -May complicate debug/backtrace > Hi Georges, In my opinion this is a bad idea. With break/continue/goto the jumps are restricted to only one function body to explicitly reduce the complexity in understanding them. With your proposal, as a user of a function I wouldn't know how deep a function returns. This can easily lead to extremely unexpected behavior. This is why exceptions are better for jumps up the call-stack, because they give the caller an explicit way of either accepting or catching the jump. > > > Regards, > Georges.L >