Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106326
To: Nikita Popov <nikita.ppv@gmail.com>, Claude Pache
 <claude.pache@gmail.com>, Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
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>
Openpgp: preference=signencrypt
Autocrypt: addr=smalyshev@gmail.com; prefer-encrypt=mutual; keydata=
 mQMuBE9mqaARCACFSqcGmNunkjQQu3X+yXnTmFeEkvM4JXZTOBdR8aEevNGmmFEfyvjaDjWi
 9hcwp4E/lYtC+P7VsVjM1OSX9eq0jC/lGL0ZyRXek+mNy0n5H1NSuTpf9Y18LMqhc4G+RU+L
 cNiZ9K0DJuOOvNLPxW7OHZguxb3wdKPXNVa2jyRfJAKm2uaJJMT1mTmFT9a0Q8SKr+mUrrJk
 uG0H2o6SzrKt8Wwoint1eh67zVsJaJtQFchnEZnlawIcqP2yC4nLGR3MkubowxoEBYCZet18
 aHVVRbvpG2Qtob8Lu5xrsGbmXymTkHTdpvkfcJFADa8MzOL90zOxXwbGfbIZOlh5En8jAQCX
 lfnx2eQL3BSW/6XANa51dbWiEp1d1BAkpGKtZvlk0Qf+M9WAi+9aXMe3xP5krxtgnRNUf2WN
 6Zdy2MxL1RRJCFbytLhl0ronC49BsGYVGshdEH8xhBbiIOJKuVZ/DTl9bEm7P9c7CC7iJyVC
 khUAhouH6xzZQNLR+RU+QebYzXypVfl99Qk7EdMmr/WAZCHLuvanyqepC5EBsa3VnAfQemSN
 oBeGBKWWLiOsPjvS72+y1z4RUMAfXHn4l/sFMt8zt7/74AmJPwZquV41p4mPO12V4+xPyc6R
 sB84sfsk2QVivU8w8AkvGQeYjXoz7Iwao95+fWteVzZ36KRQvUckP8pGjHlDXnHxJ0HI1I/k
 OBZSjwRwUf0dd73y6erPhbLk+gf+NdI3H9KGJBzG5/rVyWKwUeQ9d5ud4jTJRkQGvAP5pg76
 vEa9dogbpe4W5Z+0BfbiJSnQmQWSHiZddj/t33ptbup44Ck6ZTgdlmFYMLF1hR47PIZTDKER
 EuKYGci/vq8snZvEJP9YCw/TtiHcMdrMKcY/+Lp8lQO0GHLPB9glVhnC0db6l1Xpg1CMI8/R
 ozBMcij30EgATggC/y2zbiqAFoS9FN9nXPbe4phStqABEyeZ+nXudt7PUYTjVgcrqo8bHZCi
 sBobWC7OnKyUzxVxzUeuPkIfmZuzkLaMw2McQdvwwsNvQ0DzaLP30c1Xsm/7EIYJcOWpzlVJ
 5QrdmE0/BbQyU3RhbmlzbGF2IE1hbHlzaGV2IChQSFAga2V5KSA8c21hbHlzaGV2QGdtYWls
 LmNvbT6IegQTEQgAIgUCT2aqtAIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQL3lW
 vF2gS12XMwD9HuRIolSwIK77u8EY461y2u6sbX36n5/uo/LDQuxoi3sA/0MvpnvzOhv9Iufv
 vsZEj3E7i3h+iD5648YMwfTFCij+uQINBE9mqaAQCADfZPMpjZkkGZj3BY/7ApoLq4mwqzbh
 +CpLXwNn20tFNvSXfb8RdeXvVEb7Scx+W9qYpiaun2iXJgCVH8fgpZpR856ulT1q6uCG++CX
 ubEvip/eJkZl93/84h04KQJwsgOrAh0Om3OePRn8Pr+++0LNS0EL8uX/YHeTOGOnnmTqYTey
 SBVFdov6L4mepddfjekicKQqhL7mZh/xuq29JijT0uNNX8v4vDWQDu5dlAcdd+uB3gcXMD/P
 ginD11zp+6wtrWCm/+yBqpvDwXQX5PGUnwvbRfl7Ay3MmwmoXiecZMg0dwTSc7e0lhB4HGRH
 ZdBMJB4rHUVGdzqujK/ctOvrAAMFB/0Utb76Qe6sCMlHxVAmeE/fbo7Pi05btZ/x01r67dHf
 aMSP0riCKJ7M0OW+jAXtu9+z/BVnYisW67WWfxl2cS5tZDgiHgJARXWUOO72+sScHP8KQmTl
 1z16gyKbwY3SmyBkwcpOL35nhUWNLy93syPoY6sZUTikr2bZYukHDQ33XBPs4e6MbWKfsa9q
 aVmnlOF3k5UqChjutfHaEa4Q7VP4wBIpphHBi9MI16oJIzzBPbGl2uoedjwiZ6QeQZnSuOVY
 ZxU2d3lRA8PrtfFN1VSlpEm/VcAvtieHUYWHN0wOu+cp3Slr5XJVNjTjJhl28SlinMME54mK
 AGf2Ldr/dRwXiGEEGBEIAAkFAk9mqaACGwwACgkQL3lWvF2gS126EQD/VVd3FgjLKglClRQP
 zdfU847tqDK4zJjbmRv5vLLwoE0A+wbrQs7jVGU3NrS0AIl5vUmewpp2BKzSkepy23nWmejw
Message-ID: <98616527-805f-3425-d292-1363be26730d@gmail.com>
Date: Mon, 29 Jul 2019 14:05:36 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0)
 Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c-=9HjQHMeTeb5sggKMhtZFGoC7f0766dVavAtpVxLUDg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax
From: smalyshev@gmail.com (Stanislav Malyshev)

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?

> 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?

> 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.

-- 
Stas Malyshev
smalyshev@gmail.com