Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106296
MIME-Version: 1.0
References: <CAF+90c87_Zd07ftVe29=GdjxhxjkFG+VXfm_ZZ3QWqER50QLuA@mail.gmail.com>
 <CAF+90c8hTaL56MQDu6=8+A2iGf9T3kxhj9TMtZdmvwNNROJO3w@mail.gmail.com> <CALKiJKoEmeLmf_H4sSUZ3brdqUgtHQH+6V0WAXe-OuPG5zNc5w@mail.gmail.com>
In-Reply-To: <CALKiJKoEmeLmf_H4sSUZ3brdqUgtHQH+6V0WAXe-OuPG5zNc5w@mail.gmail.com>
Date: Thu, 25 Jul 2019 15:48:20 +0200
Message-ID: <CAF+90c8a_CWVyVfnt3so_u-0Df5zxwRX1=ASp=BXcOtGggeANg@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b8fc27058e81aeeb"
Subject: Re: [PHP-DEV] Re: [RFC] Explicit call-site send-by-ref syntax
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000b8fc27058e81aeeb
Content-Type: text/plain; charset="UTF-8"

On Thu, Jul 25, 2019 at 3:14 PM Rowan Collins <rowan.collins@gmail.com>
wrote:

> On Thu, 25 Jul 2019 at 13:32, Nikita Popov <nikita.ppv@gmail.com> wrote:
>
> > I think it can either go forward as-is, in that it constitutes the first
> > step towards bringing sanity to by-reference passing in the long term.
> >
>
>
> Hi Nikita,
>
> As I mentioned before, I think this RFC is 10 years too late: if this goes
> ahead, we'll be telling a lot of people "You know all those reference
> annotations you removed when you upgraded to PHP 5.4? You have to put them
> all back again now!"
>
> To be clear, forcing a parameter to be by-reference against the signature
> of the called function was a bad feature, and this proposal would have been
> better. But without a time machine, I think this will cause more confusion
> than it brings value.
>
> Adding "out" and "inout" keywords, as mentioned in "future scope", is a
> much more powerful change, won't require any opt-in modes or breaks to
> existing code, and would be looking forward rather than backward. It's hard
> to see how tweaking the meaning of "&" will lead us closer to that, making
> it feel more like "alternative" than "future".
>

While the out/inout keywords are conceptually nice, I don't think they
really change anything regarding the migration path. In your previous mail
you mentioned that we could make these keywords required if they are used
on the declaring function: But that does not solve the problem of existing
functions.

I think nowadays it is well known that by-reference passing is to be
avoided and I don't see it particularly commonly in user code. By-reference
passing is mainly used when it is needed to interact with existing
by-reference functions such as preg_match(). We can hardly switch these
functions to use out/inout if we require the corresponding keyword on the
call-site.

This proposal (in conjunction with the option to make it required) would
solve the main issues I have with the by-reference passing implementation
-- the out/inout approach is a refinement over that, but I'm not convinced
that it a worthwhile refinement relative to the language and engine
complexity it will introduce. It would be a necessary step if we had plans
to eliminate references from PHP entirely, but despite how much I dislike
PHP references, I don't think that eliminating references entirely is
possible even on a very long time-scale.

Nikita

--000000000000b8fc27058e81aeeb--