Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106323
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>
In-Reply-To: <CAF+90c-=9HjQHMeTeb5sggKMhtZFGoC7f0766dVavAtpVxLUDg@mail.gmail.com>
Date: Mon, 29 Jul 2019 16:34:35 +0100
Message-ID: <CALKiJKrs1Gae9h5X03yJrPckP5uZp6w_EWAEBbmY1Ka_1++wXg@mail.gmail.com>
To: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000be7509058ed3a1fa"
Subject: Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax
From: rowan.collins@gmail.com (Rowan Collins)

--000000000000be7509058ed3a1fa
Content-Type: text/plain; charset="UTF-8"

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).

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. 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".

Regards,
-- 
Rowan Collins
[IMSoP]

--000000000000be7509058ed3a1fa--