> On Feb 23, 2020, at 9:23 AM, Rowan Tommins <rowan.coll...@gmail.com> wrote:
>
> 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.
Fair point.
>
> 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.
However, if you consider editions, it may not ever need to become mandatory and
yet those who want it could still benefit.
> 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.
Uh, yeah I guess. But I would ask the question, why would you want to do that?
The reason we don't make the ampersand a requirement is a legacy concern. But
if you are writing a new function there is no legacy concern. So it would seem
a developer would *want* to force the ampersand.
Or is your point just that there are a list of possible options and you want
the ability to use _all_ options from that list regardless of whether a
specific option has a valid use-case?
>>> 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.
Sounds like the solution then is to update the documentation?
> 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.
I do agree that changes that are contradictory as problematic.
However, in this case Nikita has weighed in and said "out" is unlikely to
happen. So that seems to remove the concern about conflicts with out
parameters?
-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
