Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108727
MIME-Version: 1.0
References: <CAF+90c-Lx2dddeXGw9Ce4xbVwJ49oKu-xzNJ1TRN4HYn6_eZ4w@mail.gmail.com>
 <8B2AFC37-9425-440C-B89D-61CBAAB0CDDD@gmail.com>
In-Reply-To: <8B2AFC37-9425-440C-B89D-61CBAAB0CDDD@gmail.com>
Date: Sun, 23 Feb 2020 10:47:17 +0100
Message-ID: <CAF+90c_RKytWDhg4Mzc8rq5RggrLt5XmOAA5F63LRDLR0M5kvQ@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d402ce059f3b24dd"
Subject: Re: [PHP-DEV] [RFC] Explicit call-site pass-by-reference (again)
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000d402ce059f3b24dd
Content-Type: text/plain; charset="UTF-8"

On Fri, Feb 21, 2020 at 11:20 PM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> On 20 February 2020 14:13:58 GMT+00:00, Nikita Popov <nikita.ppv@gmail.com>
> wrote:
> >Hi internals,
> >
> >I'd like to start the discussion on the "explicit call-site
> >pass-by-reference" RFC again:
> >https://wiki.php.net/rfc/explicit_send_by_ref
>
>
> Hi Nikita,
>
> Thanks for putting the case for this so clearly. My instinctive reaction
> is still one of frustration that the pain of removing call-site ampersands
> was in vain, and I will now be asked to put most of them back in. It's also
> relevant that users already find where & should and should not be used very
> confusing. There is a potential "PR" cost of this change that should be
> weighed against the advantages.
>
> I'm also not very keen on internal functions being able to do things that
> can't be replicated on userland, and this RFC adds two: additional
> behaviour for existing "prefer-ref" arguments, and new "prefer-value"
> arguments.
>

I should say that this is a non-essential part of the RFC. I noticed that
this RFC provides a way to solve this problem, but if we don't think it the
problem is worth solving, then we don't have to solve it.

The prefer-ref/prefer-val thing is indeed a bit peculiar. It's an artifact
of the current way of implicit by-reference passing, where the decision of
whether to pass by-value or by-reference has to be made based on an
"educated guess" at the call-site. That leaves us with always-val,
always-ref, prefer-val and prefer-ref as the possible passing modes. In the
explicit by-ref passing regime, the latter two consolidate, and we have
by-val, by-ref and "either" as the options, which is a lot more obvious.

But again, I can't say I'm fully convinced myself that this is really a
problem we need to solve. I don't really care about call_user_func() at all
(it is entirely obsoleted by $fn()), and now that I think about it,
__call() isn't really the right primitive to expose anyway. If you will
allow me a little digression...

Instead of having __call(), what we really should have is __get_method().
For a simple forwarding proxy, the implementation would look something like
this:

public function __get_method(string $name): Closure {
    if (method_exists($this->proxy, $name)) {
        return Closure::fromCallable([$this->proxy, $name]);
    }
    return null;
}

This solves multiple problems with one stone: First, it preserves the
signature of the method we're proxying to: This is better than the solution
in this RFC, because it preserves both by-ref argument passing and by-ref
returns, and can validate that properly (i.e. passing a non-ref to by-ref
will diagnose). Second, it makes is_callable() work precisely, because we
no longer have to assume that with __call() any method is callable. Third,
it makes Reflection work on the proxied method.

It's possible to recover normal __call() semantics from this approach by
writing something like this:

public function __get_method(string $name): Closure {
    return function(...$args) use($name) {
        // Normal __call() implementation in here.
    };
}

My current opinion is that I'd rather wait for the details of out and inout
> parameters to be worked out, and reap higher gains for the same cost. For
> instance, if preg_match could mark $matches as "out", I'd be more happy to
> run in a mode where I needed to add a call-site keyword.
>

I believe we talked about this in some detail in the previous discussion on
this topic. My basic stance on in/out is that it's *probably* not worth the
complexity, unless it is part of an effort to eliminate references from PHP
entirely (which would be hugely beneficial). Unfortunately I don't really
see a clear pathway towards that. "out" parameters can remove one use-case
of references, and I can see how that would work both in terms of semantics
and implementation. The case of "inout" parameters is much more
problematic. While these can nominally work without references, I don't see
how they could do so efficiently (we would have to "move out" the value
from the original location to avoid COW). Similarly, I don't have any
answer to how &__get() and &offsetGet() would work without references.

Regards,
Nikita

--000000000000d402ce059f3b24dd--