> On Feb 23, 2020, at 2:00 AM, Mike Schinkel <m...@newclarity.net> wrote:
> On Feb 22, 2020, at 5:56 AM, Rowan Tommins <rowan.coll...@gmail.com> wrote:
>> One of the reasons it is confusing is because developers are currently
>> required to use the ampersand in one place and not the other. Making
>> it always used removes said confusion as they would no longer be a
>> reason to have to remember when and when not to use the ampersand
>> anymore.
>
> Maybe. I think a larger part of it is that references themselves are a
> slightly confusing concept, and the fact that & looks like an operator of its
> own (and is often documented that way) but is really an annotation on other
> operators/commands. That is, the & in $foo = &$bar and return &$bar doesn't
> modify $bar, it modifies = and return, respectively.
>
> Making the rules more logical and symmetrical would perhaps be more helpful
> to new users than it is to established users, particularly those who've known
> multiple versions of the language already.
You call out the use of the ampersand being viewed as an operator acting on a
variable as problematic, but that is already baked into current PHP, not going
to change any time soon if ever, and is orthogonal to this RFC.
So whether or not people find the ampersand operator to be confusing that is
irrelevant to the debate posed by Nikita's RFC over whether we should make the
use of ampersand related to passing-by-reference be more consistent.
>> There is a potential "PR" cost of this change that should be weighed
>> against the advantages.
>>
>> To say "We fixed something that in hindsight we've since determined was
>> a problem." How is this a concern?
>
> The concern is that the costs will be much more visible to users than the
> benefits, and they will resent the core developers pushing that requirement
> onto them, rather than thanking then for their hard work.
>
> As I said, that's not an absolute reason not to do it, it's a cost to be
> weighed.
Nikita's RFC proposes that the ampersand would be optional at the calling site,
so is it really a concern that developers will resent something that is
optional?
Yes Nikita mentioned that a future "edition" might make is a requirement, but
even then it will still be optional — developers can choose not to use the new
edition — and I think the resentment will come more from the concept of forcing
an "edition" on developers than any specific feature. Note that I plan to post
soon about how I think we can alleviate that.
So we can debate the PR "cost" of requiring ampersands at the call site when
the requiring RFC is on the table.
As a side note, I remember thinking "WTF?!?" when the requirement to use an
ampersand at the calling site was removed. It is possible your analysis of PR
cost is discounting the potential large number of people who will think adding
it back is a good think.
>>> I'm also not very keen on internal functions being able to do things
>> that can't be replicated on userland, and this RFC adds two: additional
>> behaviour for existing "prefer-ref" arguments, and new "prefer-value"
>> arguments
>>
>> So what specific problems would having these enhancement cause for the
>> language?
>
> There are two problems I have with internal-only features in general: the
> inability to polyfill and extend, and the requirement for a separate mental
> model.
>
> As an example of the first, the RFC mentions using call_user_func with a
> call-site annotation to forward the parameter by reference. The reason for
> allowing that also applies to a user-defined wrapper like
> call_with_current_user or call_with_swapped_parameters, but there's no syntax
> for those to be marked "prefer-val".
Let's analyze.
In this case there does not appear to be a need for "prefer-val." And
Nikita's RFC adds functionality we currently do not have — ability to pass by
reference to call_user_func() so that is a win over status quo as it gains a
feature that we previously internal-only:
<?php
function current_user():int {
return 1;
}
function foobar( int $current_user, int &$foo, int $bar ) {
$foo++;
$bar++;
}
function call_with_current_user(Callable $callable, int &$foo, int $bar ) {
return call_user_func( $callable, current_user(), &$foo, $bar );
}
$foo = 0;
$bar = 0;
call_with_current_user( 'foobar', &$foo, $bar );
echo $foo; // prints 1
echo $bar; // prints 0
Now if you want to use call_user_func_array() then I agree we are missing
functionality. Consider this example which envisions a new function called
`func_is_byref_arg()`. Yes the function name is a horrible name but consistent
with existing functions for related purposes:
<?php
function current_user():int {
return 1;
}
function foobar( int $current_user, int ...&$args ) {
foreach( $args as $i => $f ) {
$args[$i]++;
}
}
function call_with_current_user(Callable $callable, int ...&$args ) {
array_unshift(&$args,current_user());
$temp_args = $args;
$result = call_user_func_array( $callable, &$temp_args );
foreach( $temp_args as $i => $t ) {
if ( func_is_byref_arg( $i, $args ) ) {
$args = $temp_args[$i];
}
}
return $result;
}
$foo = 0;
$bar = 0;
$baz = 0;
call_with_current_user( 'foobar', &$foo, $bar, $baz );
echo $foo; // prints 1
echo $bar; // prints 0
echo $baz; // prints 0
In my example func_is_byref_arg($pos[,$variadic_arg]):bool accepts one
parameter if you are checking for by-ref positionally, and two if you are
introspecting a variadic parameter.
So I argue we should fill in the holes of the RFC that introduces a feature
that to help developers write more robust code instead of decline an RFC for
imperfections in its first draft.
> 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.
As I understand the RFC the behavior will still be driven by the ampersand at
the declaration site. The presence or absence of ampersand at a call still will
merely be decoration that allows developers to better convey their intent.
Can you please give an example of how this RFC would change behavior at call
site compared to a call site where the ampersand did not exist, given the
behavior of this RFC?
>>> My current opinion is that I'd rather wait for the details of out and
>> inout parameters to be worked out, and reap higher gains for the same
>> cost. For instance, if preg_match could mark $matches as "out", I'd be
>> more happy to run in a mode where I needed to add a call-site keyword.
>>
>> This sounds like preferring perfect in the (potentially distant) future
>> vs. much better today.
>
>
> No, it's preferring to hold out for a little bit more value to weigh against
> my evaluation of the cost.
>
> This is, when followed through to its conclusion of mandatory marking, a
> disruptive change to every piece of code, so we need to decide if the
> disruption is worth it.
That is disingenuous. 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.
Further, your cost analysis does not appear to consider the cost of status quo
and this RFC's ability to reduce that cost.
Using Nikita's RFC example there is a potential real-world cost to getting the
following wrong in a userland project:
$ret = array_slice($array, 0, 3);
$ret = array_splice($array, 0, 3);
With Nikita's RFC developers could chose to start using ampersand at the
calling site for these type of methods. Let's consider that I write the
following:
array_slice(&$array, 0, 3);
array_splice(&$array, 0, 3);
With this RFC (I assume) an error could be generated on array_splice(&$array,
0, 3)saying that I cannot pass the array by reference. Today we don't get
that. This alone could reduce errors that I have seen in source code and I
admittedly have committed myself.
Said succinctly, there is a (IMO significant) cost to doing nothing that your
analysis appears to ignore.
> It's also the second change in the same place, and we should be sure that
> we've got it right this time, and won't require a third change in the near
> future.
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.
> For instance, if out parameters were added, would the same line of code end
> up going from optional &, to forbidden &, to mandatory &, to mandatory "out"?
My view is that we should actually hash those concerns out and move forward
rather than state them in the abstract and let the fact that legitimate
concerns *might* exist derail an improvement to the language.
Since there are not infinite potentials, let's just address your specific
concerns here. My straw man proposal is that if we add an `out` keyword exists
then a developer could use either `out` or `&` but not both. Then in a future
"edition" of pHP it would be possible that we disallow `&` if enough people
agree that that is better. Or we could leave as either/or. Allowing ampersand
at a call site today does not block potential future `out` keywords AFAICT.
For me I don't care which it is as long as there is a calling site notation
that allows a developer to write code indicating intent and for other
developers to read code and see that intent.
Status quo waiting for some future potential that may not arrive for years does
not get us there in the near term, but Nikita's RFC would.
> I'm not strongly against the idea, but the advantages just don't feel quite
> strong enough, so if I had a vote, I'd currently be inclined to vote no.
Heh. My vote would yes. And since neither of us have a vote I guess it would be
applicable to say they cancel each other's vote out. Or not. :-D
-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
