On Sat, Mar 21, 2015 at 1:13 PM, Georges.L <cont...@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
>
