Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106328
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>
 <98616527-805f-3425-d292-1363be26730d@gmail.com>
In-Reply-To: <98616527-805f-3425-d292-1363be26730d@gmail.com>
Date: Tue, 30 Jul 2019 00:02:59 +0200
Message-ID: <CAF+90c-cT-vkWKATe+XZxzWEQ9MCLzjF2Wpyop_SXkAAkKwZag@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Claude Pache <claude.pache@gmail.com>, Rowan Collins <rowan.collins@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000198f74058ed90f29"
Subject: Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000198f74058ed90f29
Content-Type: text/plain; charset="UTF-8"

On Mon, Jul 29, 2019 at 11:05 PM Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> > This discussion seems to have lost track of the context ... the original
> > quote (which Stas cherry-picked in a way that lost the original meaning):
> >
> >> 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.
> >
> > You seem to be agreeing with what I originally said: That by-reference
> > passing is mainly useful to interoperate with by-reference internal
> > functions, which don't exactly leave you with a choice.
>
> I do not think this is accurate, at least in my experience it completely
> isn't. Also, internal function accept by-ref for a reason - e.g., they
> need to modify arrays. The same reason would apply to any user space
> functions that also need to modify arrays, and since we can't have
> internal functions for every array modification that may be needed today
> and in all the possible the future, by-ref would be as needed for
> userspace as it is needed for internal functions.
>
> > that currently, both humans, static analyzers and the engine have a hard
> > time telling whether an argument is going to be passed by reference (or
> > otherwise indirectly modified) or not. Humans may use API familiarity to
> > help them, static analyzers can (unreliably) try to infer this through
>
> Why? This can happen only if you don't know the definition of the
> function being called. For human reader, it's rather unusual situation
> to be in - if you don't know that the function does, you stop and got
> read it's definition, otherwise you can't understand what's going on
> from now on - that happens regardless of whether references are involved
> or not. Once you've read the function definition (which you need to do
> anyway) you know whether references are involved or not.
> For the static analyzer, similar logic applies, except that it probably
> already knows the definitions of all functions (how it could analyze
> anything otherwise?). Only exception is when it's variable function
> call, which is quite rare, and mixing by-ref and by-value functions in
> such calls is even rarer (pretty much never to be done), so we should
> not really optimize for this rare and un-recommended case.
>
> > global analysis, while the engine is entirely out of luck apart from the
> > simplest of cases.
>
> The engine is doing the call! If it doesn't know what function is being
> called, it's a fatal error. So here I can't even imagine a situation
> where the engine wouldn't know whether passing is by-ref or not. Do you
> mean something different by "the engine" than I do?
>

I'm referring to the compiler and optimizer here. Especially in namespaced
code we pretty much always don't have a hard guarantee on what function
will get called. This means that we have to generate code that dynamically
dispatches between by-val passing and by-ref passing (this is fairly cheap)
and more importantly, has to dynamically dispatch between read and write
fetches across opcode chains (this is less cheap). In addition to that we
have to discard any type information, and give up on essentially all
optimization in general, for any CVs that are passed to function calls,
which is pretty common (the impact is hard to quantify as it depends on
follow-on optimizations).


> > 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
>
> How can you have this guarantee? If $a is an object, it can be modified
> by anything. If $a is an array, it still be modified if any of the
> elements is by-ref. Do you mean the content of zval underlying $a is not
> modified (except maybe refcounts)? That may be guaranteed but what is
> the use of such a guarantee for the user?
>

Yes, I'm referring to the variable itself not being modified -- of course
interior mutability may still exist. From the engine (again,
compiler/optimizer) perspective we are not really concerned about interior
mutability (esp. as for arrays it may only occur if the array contains
references, which is something we track), only about mutability of the
variable itself.

> 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).
>
> That is confusing, now & doesn't actually mean by-ref, it means
> sometimes by-ref, sometimes maybe by-ref, sometimes just kidding, no
> refs at all.
>

This is pretty much the same concern I mentioned in the next paragraph. You
could have agreed with that without rephrasing things in such an
argumentative fashion.

I'm sorry Stas, but I will not be reading your mails in the future. I think
you mean well and do raise legitimate points, but I have noticed over a
long period of time that I find arguing with you to be extremely mentally
exhaustive, while ultimately deriving very little actionable benefit from
these discussions. You just rub me entirely the wrong way. That's
ultimately my own personal issue, but I don't think I can avoid acting on
it any longer. I hope your position is sufficiently well-represented by
other people.

Regards,
Nikita

--000000000000198f74058ed90f29--