Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108729
To: PHP internals <internals@lists.php.net>
References: <CAF+90c-Lx2dddeXGw9Ce4xbVwJ49oKu-xzNJ1TRN4HYn6_eZ4w@mail.gmail.com>
 <8B2AFC37-9425-440C-B89D-61CBAAB0CDDD@gmail.com>
 <08159EA6-61E5-4E85-AC43-9637783315EA@newclarity.net>
 <73831D4E-B53C-4350-BDAB-2F5BB31E2E8D@gmail.com>
 <03009039-9B2B-49BC-9CFF-CFB77BEFE2DC@newclarity.net>
Message-ID: <fd3f9fe7-5820-c438-70f2-e669ebeaee43@gmail.com>
Date: Sun, 23 Feb 2020 14:23:43 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <03009039-9B2B-49BC-9CFF-CFB77BEFE2DC@newclarity.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [RFC] Explicit call-site pass-by-reference (again)
From: rowan.collins@gmail.com (Rowan Tommins)

Hi Mike,

First, I'd just like to reiterate that I absolutely see benefits in this 
proposal, and am definitely not campaigning for it to be abandoned as a 
bad idea. Like with any proposal, we have to weigh those benefits 
against the costs, and my current personal opinion is that the scales 
come down *very slightly* on the cost side.

I will also just say that you have made some valid points about 
different ways people might perceive this change, and my fears on that 
score may be overblown.


On 23/02/2020 07:03, Mike Schinkel wrote:

> The RFC does not require mandatory use, period.
>
> The "cost" you worry about will not exist unless and until a future RFC proposes to make it mandatory and that RFC is accepted.

The RFC states very clearly that the full benefit of the change will 
only be realised by making the markers mandatory in some way, and 
includes specific discussion of how that might be introduced. Put 
simply, tools (and even humans) get most from knowing that a particular 
line of code *won't* pass anything by reference, and optional markers 
can't guarantee that.

I am analysing the proposal on that basis, just as I would analyse a 
proposed deprecation on the basis that the deprecated feature will one 
day be removed.

If we analyse it on the basis of it *never* becoming mandatory, we have 
to adjust our analysis of both costs *and* benefits.


Regarding prefer-ref and prefer-val:

> function call_with_current_user(Callable $callable, int &$foo, int $bar ) {
>     return call_user_func( $callable, current_user(), &$foo, $bar );
> }


If you define the function this way, all callers are *required* to pass 
the parameter by reference. That immediately means that this is a fatal 
error:

call_with_current_user('foobar', 42, 42);

Internal functions have the magical ability to accept both literals 
values and reference variables, whereas userland functions have to 
choose one or the other.


>> As an example of the second, even under strict settings, calls to certain internal functions will have an optional & at the call site, which changes their behaviour.
>>
>> To those without knowledge of the core, those functions simply have to be remembered as "magic", because their behaviour can't be modelled as part of the normal language.
> I am unclear how the optional ampersand at the call site will change the behavior.


I was referring to this line in the RFC:

> If the argument is a prefer-ref argument of an internal function, then 
> adding the |&| annotation will pass it by reference, while not adding 
> it will pass it by value. Outside this mode, the passing behavior 
> would instead be determined by the VM kind of the argument operand. 


That means that for any function implemented internally as "prefer-ref", 
the user can now *choose* whether their variable will be overwritten by 
the function. I don't know exactly which functions this would affect, 
because as far as I know, the manual doesn't have a standard way to 
annotate "prefer-ref". Which is kind of my point: it's magic behaviour 
which sits outside most people's understanding of the language.


> I don't particularly see a problem with requiring a third change in 
> the future. Hindsight is a wonderful clarifier. And I believe 
> elsewhere you have been debating me over the need for incremental 
> change. Caveat emptor. 


The distinction I would make is between incremental change, and 
contradictory change. If we later introduce out parameters in a way 
that's compatible with call-site &, that would indeed be incremental 
change; the effort spent adding & would move code closer to the final 
state. If we end up introducing call-site "out", the effort spent adding 
& will simply be compounded with the effort spent adding "out".

Predicting the future is a mug's game, but it's at least worth exploring 
some possible futures, and how decisions now might help or hinder them.


Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]