Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106297
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> <CAF+90c8a_CWVyVfnt3so_u-0Df5zxwRX1=ASp=BXcOtGggeANg@mail.gmail.com>
In-Reply-To: <CAF+90c8a_CWVyVfnt3so_u-0Df5zxwRX1=ASp=BXcOtGggeANg@mail.gmail.com>
Date: Thu, 25 Jul 2019 15:40:37 +0100
Message-ID: <CALKiJKruJEsXcJmYk3MRiQmPkXDBqCSRJp1ZeqPvDmPx7jcvZA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000069d79e058e826989"
Subject: Re: [PHP-DEV] Re: [RFC] Explicit call-site send-by-ref syntax
From: rowan.collins@gmail.com (Rowan Collins)

--00000000000069d79e058e826989
Content-Type: text/plain; charset="UTF-8"

On Thu, 25 Jul 2019 at 14:48, Nikita Popov <nikita.ppv@gmail.com> wrote:

>
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.
>


I guess the call-site syntax would still need to be opt-in for
compatibility reasons, but we could definitely mark the parameters as "out"
in internal functions, even if that was mainly a documentation / reflection
change.

That would stop people having to write `$matches = []; preg_match($foo,
$bar, $matches);` to ensure that the output parameter is initialised. I
have been annoyed by that more often than I've encountered a function where
I wasn't sure if the parameter was by-reference or not.


This proposal (in conjunction with the option to make it required) would
> solve the main issues I have with the by-reference passing implementation
>


If this remains optional, I wouldn't have much appetite for using it,
because the benefit feels very slight. The fact that it wouldn't always be
mandatory makes the benefit even slighter, since you still couldn't look at
foo($bar) and know whether it was by-reference without also knowing what
declare options were in scope.



>   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.
>


Would it really be that complex? The only real difference between "out" and
"&" would be automatically setting the variable to null when it was passed
to the function.

Regards,
-- 
Rowan Collins
[IMSoP]

--00000000000069d79e058e826989--