Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106341
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>
 <9aba78c9-f04d-45b8-6c34-ad1c2472ef76@gmail.com> <CADyq6sLrDh4ORdmJ4n9qKmhWjHvOzgvHhQ0PXYnDxS6SBUq6Eg@mail.gmail.com>
 <75d04139-b944-f204-f988-959fa6f3e305@gmail.com> <CADyq6sLismPxQ5-aztMh35UfOXRAfHTX3imcT04KxEHedJx7iw@mail.gmail.com>
 <8CD3B476-ABF9-4DB7-96D3-217064023854@gmail.com> <CAF+90c-=9HjQHMeTeb5sggKMhtZFGoC7f0766dVavAtpVxLUDg@mail.gmail.com>
 <CALKiJKrs1Gae9h5X03yJrPckP5uZp6w_EWAEBbmY1Ka_1++wXg@mail.gmail.com>
In-Reply-To: <CALKiJKrs1Gae9h5X03yJrPckP5uZp6w_EWAEBbmY1Ka_1++wXg@mail.gmail.com>
Date: Tue, 30 Jul 2019 11:50:48 +0200
Message-ID: <CAF+90c-n3A1w0dRFQmFN2SekOr374aOrye-CYi5xtyUtM3LP3w@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007747e8058ee2f2d5"
Subject: Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000007747e8058ee2f2d5
Content-Type: text/plain; charset="UTF-8"

On Mon, Jul 29, 2019 at 5:35 PM Rowan Collins <rowan.collins@gmail.com>
wrote:

> On Mon, 29 Jul 2019 at 15:41, Nikita Popov <nikita.ppv@gmail.com> wrote:
>
> > This proposal (at least combined with a declare that enforces use of
> > call-site annotations) addresses that concern. out/inout parameters do
> not
> > address this concern, because they are an mechanism that would be used
> *in
> > addition* to normal by-ref passing, and as such not address any problems
> it
> > has.
> >
> > The only way I see in which out/inout would actually address the concern
> > of this proposal is if out/inout were used instead of & at the call-site,
> > but the parameter were still a normal reference. I don't think that's a
> > good idea because it breaks symmetry between arguments and parameters,
> and
> > also squanders any future potential to use out/inout as a way to reduce
> > reference-use in this context.
> >
> > Does that make sense, Rowan? To put is more compactly, what I want is an
> > eventual state where given $fn($a) I have a guarantee that $a is not
> going
> > to be magically modified, without having to perform any global reasoning
> > about what $fn may refer to. If an alternative proposal does not result
> in
> > this eventual state, then it is not an alternative to this proposal (but
> > possibly still a valuable addition in itself).
> >
>
>
> It does, yes. I guess what I had in mind was that *in the long-term*,
> out/inout parameters would replace & parameters, so rather than
> declare(require_reference_at_call_site=1) you would have
> declare(disable_reference_parameters=1).
>

Something like that could in principle address the problem, though it would
enforce certain design decisions to allow reaching that eventual state. I
think this is how out/inout would have to work in order to satisfy BC
concerns while still allowing a declare-based mode that eliminates plain
by-ref passing entirely:

 * All current by-ref parameters in extensions must be changed to out/inout
parameters.
 * By default, an out/inout parameter will behave exactly like a reference
parameter and there is no behavioral difference between out/inout.
 * Additionally, the call-site is allowed to specify out/inout. If it is
specified, it must match the parameter. If it is specified, inout will
generate a notice if the passed value doesn't exist (while out behaves as
usual reference pass).
 * A declare() exists that would require require call-site out/inout
annotations and prohibit calls with reference parameters (that have not
been converted to out/inout).
 * Additional changes to type-checking for out/inout parameters in userland
functions.

One migration problem that would still exist is that 3rd-party libraries
would also have to migrate to out/inout parameters first, before users
could enable the declare() mode that disables reference-passing --
otherwise they would not be able to make use of some of the library
functionality, or would have to opt-out in parts of the code. Alternatively
one could allow the use of out/inout with normal reference parameters as
well, in which case both out/inout would be allowed at the call-site.

Whether or not it's a direct alternative to this proposal, I also worry
> that out/inout parameters are somewhat mutually exclusive with it: the more
> effort is spent on making reference parameters "better", the less appetite
> there will be for replacing them altogether.


This kind of goes both ways: There is such a thing as "good enough" and
there's also the typical effect that going from a 95% solution to a 99%
solution will often take many times more effort (what's the technical term
for this?) In this context, "effort" isn't even the right word, it's a
combination of initial implementation effort, long-term maintenance cost
and possibly most importantly, language semantic complexity.

Above, I have outlined a way in which out/inout could work while mostly
addressing my original motivation. But is this approach really better than
a simple call-site "&" annotation that flawlessly integrates into the
existing reference passing system? I'm not convinced that it is. Especially
if we need to introduce out/inout in a way that interoperates well with
references for BC/migration purposes, the semantics become fairly complex,
while (imho) not offering a lot of benefit over a simple by-reference pass.
The main benefit I see would be an opportunity to fix the current
interaction of references and type annotations.

Every time I have discussed out/inout with people before, it has been in
the context of "What would we have to do to completely remove references?"
A large part of that is finding an alternative to by-reference passing that
does not use references. Hack introduced inout parameters (see
https://hhvm.com/blog/2018/03/15/hhvm-3.25.html) specifically to avoid the
issues of reference-passing (and they behave essentially like the
desugaring I mentioned in some earlier mail). But we would not get these
benefits using the approach outlined above, and I don't believe we could
use something significantly different while still supporting existing
by-ref internal functions.

This is why I don't think these two things should be mixed. Proper
out/inout parameters should not have anything to do with references.

I agree the behaviour of type
> annotations would need deciding, but arguably that should have been true
> for by-reference parameters; it's somewhat bizarre that you can write
> "function foo(SomeClass &$x) { $x=42; }" The solution would probably be to
> reuse the "typed references" from the typed property implementation.
>
>
>
>
> > Bob has brought up another interesting issue: This proposal currently
> does
> > not address the case of foo(...$a), where references into $a may be added
> > if foo() has by-reference parameters. The suggestion was to use
> foo(&...$a)
> > -- however in this case only to *allow* the use of references, not
> require
> > it (some args may be by-val while others may be by-ref).
> >
>
>
> There's probably a bit of a rabbit-hole if the mission is "make references
> explicit". An array containing a reference can be passed by value, for
> instance, so $fn($a) might not technically modify $a, but still modify
> elements inside it. So it seems like we come back to "this is kind of
> useful information but may not actually offer a hard guarantee".
>

Right, references in arrays and objects are a pretty big WTF factor
(especially in how they behave with copying an cloning), but I don't really
have a good answer to those.

Regards,
Nikita

--0000000000007747e8058ee2f2d5--