Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101300
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.173 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <CAF+90c87_Zd07ftVe29=GdjxhxjkFG+VXfm_ZZ3QWqER50QLuA@mail.gmail.com>
References: <CAF+90c87_Zd07ftVe29=GdjxhxjkFG+VXfm_ZZ3QWqER50QLuA@mail.gmail.com>
Date: Sun, 10 Dec 2017 19:29:51 -0700
Message-ID: <CAFMT4No0sJD=Q1PKazk8F+SEQ015u0AKd8xXVWfKWBVJ_SRDFg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax
From: levim@php.net (Levi Morrison)

On Wed, Dec 6, 2017 at 12:49 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> Hi internals,
>
> I'd like propose optional support for explicitly marking by-reference
> argument passing at the call-site, in addition to the declaration-site:
>
>     https://wiki.php.net/rfc/explicit_send_by_ref
>
> In short, while currently we have
>
>     function byRef(&$ref) {...}
>     byRef($var);
>
> this proposal would also allow
>
>     function byRef(&$ref) {...}
>     byRef(&$var);
>
> so that the use of by-reference passing is obvious without having to
> consult the function declaration.

I think we ought to commit to requiring the ampersand at the call site
some point in the future. As others have noted it provides little
benefit at the call site if it is not required.

However, there is an area where this does provide value that others
have not yet mentioned or thought of: `callable` parameters.

    public function apply(callable $f) {
        return $f(&$this->data);
    }

This requires the callable to accept the argument by reference,
something we cannot currently require. Of course this is rarely
needed; I am merely pointing out this feature is more than a syntactic
hint to humans.

Based on the current discussion I would vote yes on this RFC, despite
the concerns raised by others.