Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85367
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain beberlei.de from 74.125.82.169 cause and error)
MIME-Version: 1.0
In-Reply-To: <CACjyb+xrqDhyBNjUBhedFH6faaPKamV7o2j1ChUEoVodgo-bnw@mail.gmail.com>
References: <CACjyb+xrqDhyBNjUBhedFH6faaPKamV7o2j1ChUEoVodgo-bnw@mail.gmail.com>
Date: Sat, 21 Mar 2015 14:20:36 +0100
Message-ID: <CAEPJdunjGoA9HJsvBgouitnsyY0_f7XNZ=Ey98FyVwY0R51rMw@mail.gmail.com>
To: "Georges.L" <contact@geolim4.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c1b8f06b9de50511cc4c7d
Subject: Re: [PHP-DEV] RFC: Nested enclosing returns
From: kontakt@beberlei.de (Benjamin Eberlei)

--001a11c1b8f06b9de50511cc4c7d
Content-Type: text/plain; charset=UTF-8

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
>

--001a11c1b8f06b9de50511cc4c7d--