Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110125
MIME-Version: 1.0
References: <171dee3baf3.bef5753260554.3262181919550021853@manuelcanga.dev>
 <CAKuGYLQ7s7Xbf1bHw83aDW0=2mNT9mkZ0XTHMz9t69EUGxvUyA@mail.gmail.com>
 <171e05b4ced.1041f31b5124598.4028595156690203917@manuelcanga.dev>
 <10faa29f-f08f-a73e-b76d-683f5abbee86@gmail.com> <171f30b0df0.102b810be444185.2462173785894899100@manuelcanga.dev>
In-Reply-To: <171f30b0df0.102b810be444185.2462173785894899100@manuelcanga.dev>
Date: Mon, 11 May 2020 11:34:22 +0200
Message-ID: <CAF+90c-hK+Yqir4a3D16F5b3mUpNE_rM6MO8qSC2dCUn24vvpA@mail.gmail.com>
To: Manuel Canga <php@manuelcanga.dev>
Cc: Rowan Tommins <rowan.collins@gmail.com>, internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000049964605a55c0e89"
Subject: Re: [PHP-DEV] [RFC] Keep type of reference params
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000049964605a55c0e89
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, May 8, 2020 at 8:49 AM Manuel Canga <php@manuelcanga.dev> wrote:

>
>
>
>
>  ---- En lun, 04 may 2020 19:33:51 +0200 Rowan Tommins <
> rowan.collins@gmail.com> escribi=C3=B3 ----
>  > On 04/05/2020 16:43, Manuel Canga wrote:
>  > > I think I=E2=80=99d be positive of adding `inout` keyword in order t=
o:
>  > >
>  > > - Check type of out is equal to type of param( like example of my
> first email ).
>  > > - Avoid modifying caller var value when the function throws an
> exception
>  >
>  >
>  > Another huge advantage of adding inout parameters is that we could mak=
e
>  > it mandatory to mark at the call-site, and get the advantages of this
>  > RFC with less of the compatibility hassle of changing the way
> references
>  > work: https://wiki.php.net/rfc/explicit_send_by_ref
>  >
>  > We'd still need to figure out how to smoothly transition built-in
>  > functions to use inout rather than by-ref parameters; but then we
>  > already have magic "prefer-ref" in internal functions, so maybe we
> could
>  > come up with some kind of "prefer-inout".
>  >
>
>
> Hi, Rowan. That's a good point.
>
> If nobody objects to this RFC, could someone give me(manuelcanga user )
> karma in order to create wiki page ?.
>

I'm finding it hard to follow what is actually being proposed here at this
point (as many different ideas seems to be discussed at the same time).
I've granted you RFC karma on the wiki in case you want to write down
something.

As other's have mentioned, this is not a simple topic from the
implementation side, so it's good to have a firm idea of how things would
work on a technical level. If you want to pursue the "inout" idea, I would
recommend reading through https://externals.io/message/101254 in its
entirety, because there is quite a bit of inout related discussion in
there. My current assessment is that I do not see any way to implement
inout in a way that both does not use references and has acceptable
performance. (Implementing inout on top of references is possible, but has
impact on its behavior, e.g. the fact that the reference will be
initialized to null by default, even if the function throws.)

One of the core problems is that any naive approach to inout (i.e.
literally implementing it as a read before the call and a write after the
call) will necessitate a copy of the modified value, precluding rc=3D1 cow
avoidance. Implementing array_push() as an inout operation would copy the
array every time a value is pushed. Maybe this is actually a fundamental
implementation-independent property of inout, if it has the semantics that
the original value is not changed on exception (a copy would be necessary
in case code later in the function throws.)

Regards,
Nikita

--00000000000049964605a55c0e89--