Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110165
Date: Fri, 15 May 2020 13:49:34 +0200
To: "Nikita Popov" <nikita.ppv@gmail.com>
Cc: "Rowan Tommins" <rowan.collins@gmail.com>,
	"internals" <internals@lists.php.net>
Message-ID: <172182ab93b.10cb04051144851.7293553067642036651@manuelcanga.dev>
In-Reply-To: <CAF+90c-hK+Yqir4a3D16F5b3mUpNE_rM6MO8qSC2dCUn24vvpA@mail.gmail.com>
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> <CAF+90c-hK+Yqir4a3D16F5b3mUpNE_rM6MO8qSC2dCUn24vvpA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Importance: Medium
User-Agent: Zoho Mail
Subject: Re: [PHP-DEV] [RFC] Keep type of reference params
From: php@manuelcanga.dev (Manuel Canga)

Hi, Internals,


 ---- En lun, 11 may 2020 11:34:22 +0200 Nikita Popov <nikita.ppv@gmail.com=
> escribi=C3=B3 ----
 >=20
 > I'm finding it hard to follow what is actually being proposed here at th=
is
 > 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.
 >=20
 > 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 woul=
d
 > work on a technical level. If you want to pursue the "inout" idea, I wou=
ld
 > 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 h=
as
 > impact on its behavior, e.g. the fact that the reference will be
 > initialized to null by default, even if the function throws.)
 >=20
 > 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 th=
e
 > call) will necessitate a copy of the modified value, precluding rc=3D1 c=
ow
 > avoidance. Implementing array_push() as an inout operation would copy th=
e
 > array every time a value is pushed. Maybe this is actually a fundamental
 > implementation-independent property of inout, if it has the semantics th=
at
 > the original value is not changed on exception (a copy would be necessar=
y
 > in case code later in the function throws.)
 >=20
 > Regards,
 > Nikita
=20

Nikita, I've already read your thread. I like your purpose about "Explicit =
call-site send-by-ref syntax". I don't understand why it wasn't accepted.=
=20
Yes, you're right about performance then maybe this RFC doesn't make much s=
ense. :(

Thanks, anyway. You can remove my karma again.

Regards
--
Manuel Canga