[RFC] Explicit call-site send-by-ref syntax

Hi internals,

I'd like propose optional support for explicitly marking by-reference
argument passing at the call-site, in addition to the declaration-site:

https://wiki.php.net/rfc/explicit_send_by_ref

In short, while currently we have

function byRef(&$ref) {...}
byRef($var);

this proposal would also allow

function byRef(&$ref) {...}
byRef(&$var);

so that the use of by-reference passing is obvious without having to
consult the function declaration.

Regards,
Nikita

Hi internals,

I'd like propose optional support for explicitly marking by-reference
argument passing at the call-site, in addition to the declaration-site:

https://wiki.php.net/rfc/explicit_send_by_ref

In short, while currently we have

function byRef(&$ref) {...}
byRef($var);

this proposal would also allow

function byRef(&$ref) {...}
byRef(&$var);

so that the use of by-reference passing is obvious without having to
consult the function declaration.

Regards,
Nikita

I've rebased and finished the implementation for this and would like to
move forward with this RFC.

I think it can either go forward as-is, in that it constitutes the first
step towards bringing sanity to by-reference passing in the long term. Or I
could first try to push through
https://wiki.php.net/rfc/namespace_scoped_declares or some variant thereof
so that call-site reference passing annotations can be made required on a
per-library/project basis.

As most of the feedback here has been on whether this is really worthwhile
if it's only optional, I guess the second option would be preferred?

Nikita

Hi internals,

I'd like propose optional support for explicitly marking by-reference
argument passing at the call-site, in addition to the declaration-site:

https://wiki.php.net/rfc/explicit_send_by_ref

In short, while currently we have

function byRef(&$ref) {...}
byRef($var);

this proposal would also allow

function byRef(&$ref) {...}
byRef(&$var);

so that the use of by-reference passing is obvious without having to
consult the function declaration.

Regards,
Nikita

I've rebased and finished the implementation for this and would like to
move forward with this RFC.

I think it can either go forward as-is, in that it constitutes the first
step towards bringing sanity to by-reference passing in the long term. Or I
could first try to push through
https://wiki.php.net/rfc/namespace_scoped_declares or some variant thereof
so that call-site reference passing annotations can be made required on a
per-library/project basis.

As most of the feedback here has been on whether this is really worthwhile
if it's only optional, I guess the second option would be preferred?

Nikita

I think this can go as-is and a namespace scoped declare (or something
similar)
could always be added after the fact to make it required to use via a
declare
statement.

Small semi-related tangent but maybe in conjunction to the strict comparison
RFC and making it mandatory to use '&' at the call site via some way,
we could have some "meta" declare statement which automatically would
enable strict types, mark reference at call site and the strict comparison.
Just an idea which I'm not sure is that wise.

Best regards

George P. Banyard

I think it can either go forward as-is, in that it constitutes the first
step towards bringing sanity to by-reference passing in the long term.

Hi Nikita,

As I mentioned before, I think this RFC is 10 years too late: if this goes
ahead, we'll be telling a lot of people "You know all those reference
annotations you removed when you upgraded to PHP 5.4? You have to put them
all back again now!"

To be clear, forcing a parameter to be by-reference against the signature
of the called function was a bad feature, and this proposal would have been
better. But without a time machine, I think this will cause more confusion
than it brings value.

Adding "out" and "inout" keywords, as mentioned in "future scope", is a
much more powerful change, won't require any opt-in modes or breaks to
existing code, and would be looking forward rather than backward. It's hard
to see how tweaking the meaning of "&" will lead us closer to that, making
it feel more like "alternative" than "future".

(For those without threaded mail clients, the RFC in question is
https://wiki.php.net/rfc/explicit_send_by_ref Incidentally, the "Proposed
for" on the RFC needs updating!)

Regards,

Rowan Collins
[IMSoP]

On Thu, Jul 25, 2019 at 3:14 PM Rowan Collins rowan.collins@gmail.com
wrote:

I think it can either go forward as-is, in that it constitutes the first
step towards bringing sanity to by-reference passing in the long term.

Hi Nikita,

As I mentioned before, I think this RFC is 10 years too late: if this goes
ahead, we'll be telling a lot of people "You know all those reference
annotations you removed when you upgraded to PHP 5.4? You have to put them
all back again now!"

To be clear, forcing a parameter to be by-reference against the signature
of the called function was a bad feature, and this proposal would have been
better. But without a time machine, I think this will cause more confusion
than it brings value.

Adding "out" and "inout" keywords, as mentioned in "future scope", is a
much more powerful change, won't require any opt-in modes or breaks to
existing code, and would be looking forward rather than backward. It's hard
to see how tweaking the meaning of "&" will lead us closer to that, making
it feel more like "alternative" than "future".

While the out/inout keywords are conceptually nice, I don't think they
really change anything regarding the migration path. In your previous mail
you mentioned that we could make these keywords required if they are used
on the declaring function: But that does not solve the problem of existing
functions.

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.

This proposal (in conjunction with the option to make it required) would
solve the main issues I have with the by-reference passing implementation
-- the out/inout approach is a refinement over that, but I'm not convinced
that it a worthwhile refinement relative to the language and engine
complexity it will introduce. It would be a necessary step if we had plans
to eliminate references from PHP entirely, but despite how much I dislike
PHP references, I don't think that eliminating references entirely is
possible even on a very long time-scale.

Nikita

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.

I guess the call-site syntax would still need to be opt-in for
compatibility reasons, but we could definitely mark the parameters as "out"
in internal functions, even if that was mainly a documentation / reflection
change.

That would stop people having to write $matches = []; preg_match($foo, $bar, $matches); to ensure that the output parameter is initialised. I
have been annoyed by that more often than I've encountered a function where
I wasn't sure if the parameter was by-reference or not.

This proposal (in conjunction with the option to make it required) would

solve the main issues I have with the by-reference passing implementation

If this remains optional, I wouldn't have much appetite for using it,
because the benefit feels very slight. The fact that it wouldn't always be
mandatory makes the benefit even slighter, since you still couldn't look at
foo($bar) and know whether it was by-reference without also knowing what
declare options were in scope.

the out/inout approach is a refinement over that, but I'm not convinced
that it a worthwhile refinement relative to the language and engine
complexity it will introduce.

Would it really be that complex? The only real difference between "out" and
"&" would be automatically setting the variable to null when it was passed
to the function.

Regards,

Rowan Collins
[IMSoP]

On Thu, Jul 25, 2019 at 4:41 PM Rowan Collins rowan.collins@gmail.com
wrote:

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.

I guess the call-site syntax would still need to be opt-in for
compatibility reasons, but we could definitely mark the parameters as "out"
in internal functions, even if that was mainly a documentation / reflection
change.

That would stop people having to write $matches = []; preg_match($foo, $bar, $matches); to ensure that the output parameter is initialised. I
have been annoyed by that more often than I've encountered a function where
I wasn't sure if the parameter was by-reference or not.

Eww, please don't write code like that...

This proposal (in conjunction with the option to make it required) would

solve the main issues I have with the by-reference passing implementation

If this remains optional, I wouldn't have much appetite for using it,
because the benefit feels very slight. The fact that it wouldn't always be
mandatory makes the benefit even slighter, since you still couldn't look at
foo($bar) and know whether it was by-reference without also knowing what
declare options were in scope.

For a drive-by contribution to an open-source project? Maybe not. For
anything that you want to work on seriously (say your own code or your
employers code), you'll want to check the declares and then have guarantees
on how the language behaves. It's somewhat off-topic, but as George
mentioned in his email, this doesn't have to be an agglomeration of
individual declares that are randomly flipped on and off: It could also be
something like a "language level" (like editions in rust).

To sick with the analogy of Rust editions, think of it as switching your
project to PHP 2020 -- where passing by-reference requires a call-site
annotation, use of dynamic properties throws, operators have stricter type
requirements, etc... So if you see foo($x) in your code, that's definitely
a by-value pass!

the out/inout approach is a refinement over that, but I'm not convinced
that it a worthwhile refinement relative to the language and engine
complexity it will introduce.

Would it really be that complex? The only real difference between "out" and
"&" would be automatically setting the variable to null when it was passed
to the function.

That depends on how the feature is supposed to work. For me, the main point
of having out/inout would be a move away from references, so this would
require the implementation of an entirely new calling convention for out
and inout parameters.

I would expect that

$z = foo($x, out $y)

would translate (in terms of behavior, not actual implementation) to
something like

[$z, $y] = foo($x)

and

$z = foo($x, inout $y)

to

[$z, $y] = foo($x, $y)

The behavior of type annotations should also change, "out T $x" should
check that the value assigned to $x on function exist (or possibly on every
write to the variable?) is T. "inout T $x" should check that $x is T on
entry, and also on exit (or on every assignment).

This would be a pretty non-trivial change. The technically hardest parts
would be the changes to type-hint behavior (depending on semantic details)
and making this work if call-site annotations are missing (very hard). I
think we should only do this if the call-site annotations are required
(still leaving the problem of old functions).

Of course, that's just what I have in mind ... the alternative (and likely
what you have in mind) is to make out/inout parameters basically normal
by-reference parameters, with the only difference that inout uses an RW
fetch instead of a W fetch and thus throws a notice if the referenced
variable does not exist. That's certainly a possibility (and technically
much simpler), but I also think that it squanders most of the potential
behind out/inout parameters.

Nikita

That would stop people having to write $matches = []; preg_match($foo, $bar, $matches);

Eww, please don't write code like that...

Huh? How would you write it then?

The behavior of type annotations should also change, "out T $x" should

check that the value assigned to $x on function exist (or possibly on every
write to the variable?) is T. "inout T $x" should check that $x is T on
entry, and also on exit (or on every assignment).

Ah, you're right, I hadn't thought about the implications for type checks.

Still, I'd rather wait for an actual new feature like this than dig into my
repo and revert the PHP 5.4 update commit so that all the call-site
ampersands are back, but still with all the drawbacks of references.
Contrary to the RFC, I have never thought of this as "PHP 4 behaviour",
because I used it right up until 5.3, exactly how this RFC is now
suggesting is the future. (I guess I should have paid more attention to
deprecation notices at the time!)

Regards,

Rowan Collins
[IMSoP]

Hi!

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

I don't think it's true. It depends on the style of coding, of course,
but there are many situations where the most convenient solution is
by-ref passing, mostly when single function can change more than one
thing. Of course there are ways around it, but they are less convenient
and less intuitive.
Additionally, if you want a function to do some mutation with arrays,
there's only two ways of doing it - either returning the resulting array
(which can double the data) or pass by-ref. Again, there are ways around
it, but again they are less convenient.
And, if your own argument recognizes internal functions have legitimate
reasons to use references, the same comes for user functions too - they
could implement similar functionality.

Stas Malyshev
smalyshev@gmail.com

Hi!

In short, while currently we have

function byRef(&$ref) {...}
byRef($var);

this proposal would also allow

function byRef(&$ref) {...}
byRef(&$var);

I am not sure why it is necessary. If you call a function, one would
assume you know what it is doing, at least you know its definition, and
with any modern IDE if you do not, it is a matter of one click (or less)
to reveal what the function does. So what is the point to mark it again?
Does not seem to add anything that the writer or reader doesn't know or
could easily find out.
It could also imply that if the call site does not bear & mark, then the
parameter can not be modified - which is not true (or only true for
primitive values) and would add to the confusion.

I think it can either go forward as-is, in that it constitutes the first
step towards bringing sanity to by-reference passing in the long term. Or I

Could you explain what you mean by "bringing sanity to by-reference
passing"? Maybe if it would be clearer what you're getting at, in that
context this proposal would be more understandable.

could first try to push through
https://wiki.php.net/rfc/namespace_scoped_declares or some variant thereof
so that call-site reference passing annotations can be made required on a
per-library/project basis.

That certainly would be very annoying and I would be very much against
it (and in general against the idea of fragmenting the language into a
thousand of tiny pieces with different syntax by adding more and more
local syntax-changing options) but I think this should be discussed
separately so I'll say no more here.

--
Stas Malyshev
smalyshev@gmail.com

Hi!

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

I don't think it's true. It depends on the style of coding, of course,
but there are many situations where the most convenient solution is
by-ref passing, mostly when single function can change more than one
thing.

Nah, by-ref is pretty much avoided in OSS packages, but we can surely
survey the ecosystem to verify this.

Hi!

Nah, by-ref is pretty much avoided in OSS packages, but we can surely
survey the ecosystem to verify this.

I literally work with code that uses references every day. So may be you
haven't encountered it but the attitude of "nah, never happens" I think
is a bit misplaced.
Also please remember not all PHP code is latest composer packages. In
fact, most of it isn't.

Stas Malyshev
smalyshev@gmail.com

On Sun, Jul 28, 2019 at 9:06 PM Stanislav Malyshev smalyshev@gmail.com
wrote:

Hi!

Nah, by-ref is pretty much avoided in OSS packages, but we can surely
survey the ecosystem to verify this.

I literally work with code that uses references every day. So may be you
haven't encountered it but the attitude of "nah, never happens" I think
is a bit misplaced.
Also please remember not all PHP code is latest composer packages. In
fact, most of it isn't.

I do work with code like that: the teams maintaining these codebases are
actively removing by-ref calls when they encounter them.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Hi!

I do work with code like that: the teams maintaining these codebases are
actively removing by-ref calls when they encounter them. 

You seem to be intent on equating your personal experience with needs of
every PHP developer on the planet. I can't prevent that but I can say
that this experience is limited and does not match what is happening in
parts of the PHP world you are not personally experiencing.

--
Stas Malyshev
smalyshev@gmail.com

Le 28 juil. 2019 à 21:12, Marco Pivetta ocramius@gmail.com a écrit :

On Sun, Jul 28, 2019 at 9:06 PM Stanislav Malyshev smalyshev@gmail.com
wrote:

Hi!

Nah, by-ref is pretty much avoided in OSS packages, but we can surely
survey the ecosystem to verify this.

I literally work with code that uses references every day. So may be you
haven't encountered it but the attitude of "nah, never happens" I think
is a bit misplaced.
Also please remember not all PHP code is latest composer packages. In
fact, most of it isn't.

I do work with code like that: the teams maintaining these codebases are
actively removing by-ref calls when they encounter them.

Marco Pivetta

Do your teams actively remove direct calls to array_push() and array_multisort()? In any case, I’m sure that most PHP developers don’t.

—Claude

Le 28 juil. 2019 à 21:12, Marco Pivetta ocramius@gmail.com a écrit :

On Sun, Jul 28, 2019 at 9:06 PM Stanislav Malyshev smalyshev@gmail.com
wrote:

Hi!

Nah, by-ref is pretty much avoided in OSS packages, but we can surely
survey the ecosystem to verify this.

I literally work with code that uses references every day. So may be you
haven't encountered it but the attitude of "nah, never happens" I think
is a bit misplaced.
Also please remember not all PHP code is latest composer packages. In
fact, most of it isn't.

I do work with code like that: the teams maintaining these codebases are
actively removing by-ref calls when they encounter them.

Marco Pivetta

Do your teams actively remove direct calls to array_push() and
array_multisort()? In any case, I’m sure that most PHP developers don’t.

Yes: usually replaced by [] or wrappers of those functions that
de-reference the variables, so that no references are used.

On Mon, Jul 29, 2019 at 10:40 AM Claude Pache claude.pache@gmail.com
wrote:

Le 28 juil. 2019 à 21:12, Marco Pivetta ocramius@gmail.com a écrit :

On Sun, Jul 28, 2019 at 9:06 PM Stanislav Malyshev smalyshev@gmail.com
wrote:

Hi!

Nah, by-ref is pretty much avoided in OSS packages, but we can surely
survey the ecosystem to verify this.

I literally work with code that uses references every day. So may be you
haven't encountered it but the attitude of "nah, never happens" I think
is a bit misplaced.
Also please remember not all PHP code is latest composer packages. In
fact, most of it isn't.

I do work with code like that: the teams maintaining these codebases are
actively removing by-ref calls when they encounter them.

Marco Pivetta

Do your teams actively remove direct calls to array_push() and
array_multisort()? In any case, I’m sure that most PHP developers don’t.

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.

In any case, I think the popularity of by-reference passing ultimately
doesn't really matter much: By-reference passing still exists, will
continue to exist and we have to deal with it.

Which is also why I think that the question of out/inout parameters is
quite orthogonal to this proposal: The problem I'm trying to address is
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
global analysis, while the engine is entirely out of luck apart from the
simplest of cases.

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).

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).

I'm not sure whether I like that idea or not. I think there's value in
making it clear that an unpack may be by reference, but at the same time I
find the discrepancy between foo(&$a) (must be ref) and foo(&...$a)
(may be ref) somewhat confusing.

Regards,
Nikita

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]

Le 29 juil. 2019 à 16:40, Nikita Popov nikita.ppv@gmail.com a écrit :

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.

To be clear: No, I’m not agreeing with: “That by-reference passing is mainly useful to interoperate with by-reference internal functions”. I don’t think that every PHP developer consider that the design of array_push() and array_multisort() is flawed, and that they must avoid such a pattern in their own user-defined functions.

More generally, I don’t think that every PHP developer consider that only the latest trendy coding style is valid, or that every legacy code not following that style should be rewritten.

—Claude

I guess what I had in mind was that in the long-term,
out/inout parameters would replace & parameters,

Excuse my ignorance (presumably about the complexity involved) if this is obvious, but if out/inout parameters are considered to be a better solution for the problem references generally solve (I don’t doubt that they are, even as a user of references), why is that inherently a “long term” goal? Is it not a feasible goal for next years release?

Cheers
Stephen

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

Hi!

Do your teams actively remove direct calls to `array_push()` and
`array_multisort()`? In any case, I’m sure that most PHP developers don’t.

Yes: usually replaced by [] or wrappers of those functions that
de-reference the variables, so that no references are used.

Again, by "usually" you mean "I do that" and maybe "my friends do that",
but that claim is not generally true. Also, array_push() is pretty bad
example here as it is pretty much the only by-ref function that has an
almost perfect syntax analogue in the language ([]). None of the others do.

--
Stas Malyshev
smalyshev@gmail.com

On Mon, Jul 29, 2019 at 11:05 PM Stanislav Malyshev smalyshev@gmail.com
wrote:

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?

I'm referring to the compiler and optimizer here. Especially in namespaced
code we pretty much always don't have a hard guarantee on what function
will get called. This means that we have to generate code that dynamically
dispatches between by-val passing and by-ref passing (this is fairly cheap)
and more importantly, has to dynamically dispatch between read and write
fetches across opcode chains (this is less cheap). In addition to that we
have to discard any type information, and give up on essentially all
optimization in general, for any CVs that are passed to function calls,
which is pretty common (the impact is hard to quantify as it depends on
follow-on optimizations).

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?

Yes, I'm referring to the variable itself not being modified -- of course
interior mutability may still exist. From the engine (again,
compiler/optimizer) perspective we are not really concerned about interior
mutability (esp. as for arrays it may only occur if the array contains
references, which is something we track), only about mutability of the
variable itself.

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.

This is pretty much the same concern I mentioned in the next paragraph. You
could have agreed with that without rephrasing things in such an
argumentative fashion.

I'm sorry Stas, but I will not be reading your mails in the future. I think
you mean well and do raise legitimate points, but I have noticed over a
long period of time that I find arguing with you to be extremely mentally
exhaustive, while ultimately deriving very little actionable benefit from
these discussions. You just rub me entirely the wrong way. That's
ultimately my own personal issue, but I don't think I can avoid acting on
it any longer. I hope your position is sufficiently well-represented by
other people.

Regards,
Nikita

Den 2019-07-29 kl. 20:00, skrev Stephen Reay:

I guess what I had in mind was that in the long-term,
out/inout parameters would replace & parameters,
Excuse my ignorance (presumably about the complexity involved) if this is obvious, but if out/inout parameters are considered to be a better solution for the problem references generally solve (I don’t doubt that they are, even as a user of references), why is that inherently a “long term” goal? Is it not a feasible goal for next years release?

Cheers
Stephen

To replace current PHP way of handling parameters is for sure a
long-term goal,
just imagine the BC break...

To introduce out/inout parameters without phasing out references is probably
a shorter goal to accomplish.

r//Björn L

Den 2019-07-25 kl. 14:32, skrev Nikita Popov:

Hi internals,

I'd like propose optional support for explicitly marking by-reference
argument passing at the call-site, in addition to the declaration-site:

 https://wiki.php.net/rfc/explicit_send_by_ref

In short, while currently we have

 function byRef(&$ref) {...}
 byRef($var);

this proposal would also allow

 function byRef(&$ref) {...}
 byRef(&$var);

so that the use of by-reference passing is obvious without having to
consult the function declaration.

Regards,
Nikita

I've rebased and finished the implementation for this and would like to
move forward with this RFC.

I think it can either go forward as-is, in that it constitutes the first
step towards bringing sanity to by-reference passing in the long term. Or I
could first try to push through
https://wiki.php.net/rfc/namespace_scoped_declares or some variant thereof
so that call-site reference passing annotations can be made required on a
per-library/project basis.

As most of the feedback here has been on whether this is really worthwhile
if it's only optional, I guess the second option would be preferred?

Nikita

Hi,

I like this proposal since it gives the programmer one more tool to improve
readability and thereby quality of code.

It will also contribute to make PHP faster. So the argument that one
shouldn't
encourage usage of references by introducing this, will then hinder
potential
performance improvements.

The decision about how to make Namespace scoped declares can come later,
still the ongoing discussion is valuable.

r//Björn L

Den 2019-07-30 kl. 00:27, skrev Björn Larsson:

Den 2019-07-29 kl. 20:00, skrev Stephen Reay:

I guess what I had in mind was that in the long-term,
out/inout parameters would replace & parameters,
Excuse my ignorance (presumably about the complexity involved) if
this is obvious, but if out/inout parameters are considered to be a
better solution for the problem references generally solve (I don’t
doubt that they are, even as a user of references), why is that
inherently a “long term” goal? Is it not a feasible goal for next
years release?

Cheers
Stephen

To replace current PHP way of handling parameters is for sure a
long-term goal, just imagine the BC break...

To introduce out/inout parameters without phasing out references
is probably a shorter goal to accomplish.

r//Björn L

PS I meant "replace current PHP way of handling reference parameters".

Hi!

I'm referring to the compiler and optimizer here. Especially in
namespaced code we pretty much always don't have a hard guarantee on
what function will get called. This means that we have to generate code
that dynamically dispatches between by-val passing and by-ref passing
(this is fairly cheap) and more importantly, has to dynamically dispatch
between read and write fetches across opcode chains (this is less

OK, now I understand where this is coming from. While I appreciate the
difficulty (though not sure how common is that - I mean, in about
99.9999% cases the natural guess about which function it is would be the
global function, overriding global functions with namespaced ones is
pretty rare), I am not sure introducing new language construct (or
resurrecting old one which we decided to drop, at this point it's
virtually the same) - yet more mandate its usage over the whole PHP
codebase! - is the right way to solve an optimization problem in
optimizer code. Optimization is nice, but it should not make things
harder for the user.

I'm sorry Stas, but I will not be reading your mails in the future. I

That's surely a great way to discuss making sweeping changes to the
language. If you encounter disagreement - just stop reading mails and
ignore whoever disagrees.

--
Stas Malyshev
smalyshev@gmail.com

I'm sorry Stas, but I will not be reading your mails in the future. I think you mean
well and do raise legitimate points, but I have noticed over a long period of time
that I find arguing with you to be extremely mentally exhaustive, while
ultimately deriving very little actionable benefit from these discussions. You just
rub me entirely the wrong way. That's ultimately my own personal issue, but I
don't think I can avoid acting on it any longer. I hope your position is sufficiently
well-represented by other people.

Nikita,

I'm sorry, but that is completely unacceptable. I'm another person with whom you used this approach in practice (and said as much, twice), even if you didn't go quite as far as saying that it will be your ongoing policy (and ignored my feedback on this). While disregarding a person's opinion (especially one that's a core contributor) is unacceptable by itself - it's even worse since claiming that "others will represent the position" is playing make-belief. The reality (based on track record) is that you very much tend to simply ignore strong & well-reasoned opposition to your proposals. This has no place on internals.

If you can't thoroughly discuss the merits and issues of your proposals, don't propose. Better yet - if you think that a proposal coming from you is likely to result in a discussion that will mentally exhaust you - don't propose it. It probably means it's far outside consensus and has no place in PHP.

Regards,

Zeev

Le mer. 6 déc. 2017 à 20:50, Nikita Popov nikita.ppv@gmail.com a écrit :

Hi internals,

I'd like propose optional support for explicitly marking by-reference
argument passing at the call-site, in addition to the declaration-site:

https://wiki.php.net/rfc/explicit_send_by_ref

In short, while currently we have

function byRef(&$ref) {...}
byRef($var);

this proposal would also allow

function byRef(&$ref) {...}
byRef(&$var);

so that the use of by-reference passing is obvious without having to
consult the function declaration.

I fully support this RFC. I've been caught many times forgetting about the
fact some argument was modified by reference. Putting this information on
the call side would definitely make code faster to decipher.

References are part of the language. The fact that some think they should
be avoided is orthogonal to the proposal. It's good to improve them. Also I
think enough time has passed since php4's call-by-ref for the syntax to be
reused now. I think it's unfair to call the RFC a reminiscent of
call-by-ref BTW.

About requiring such call-annotations using a "declare" directive it feels
like a heated topic. But we don't need it, so let's split it appart. I
could very well see userland tools enforce it at the CS-checking level.
That would provide 99.999% of the target benefit while saving us some
mental health issues and some unneeded technical challenges to solve.

My 2 cts,
Nicolas

On Tue, 30 Jul 2019 at 07:14, Nicolas Grekas nicolas.grekas@gmail.com
wrote:

I think enough time has passed since php4's call-by-ref for the syntax to
be
reused now. I think it's unfair to call the RFC a reminiscent of
call-by-ref BTW.

Firstly, please let's stop calling this a "PHP 4" feature. It was fully
supported right up to 5.2, deprecated in 5.3, and only removed in 5.4.

Secondly, I completely disagree that it's unfair to compare the two. The
syntax being proposed in this RFC (& at both call-site and definition-site)
was supported by versions prior to PHP 5.4. Those versions left it optional
at either side, which was certainly a mistake; but it was perfectly
possible (and probably common) for coding standards to require it in both
locations.

It might be a good idea to include a more thorough discussion of this
history in the RFC.

About requiring such call-annotations using a "declare" directive it feels
like a heated topic. But we don't need it, so let's split it appart. I
could very well see userland tools enforce it at the CS-checking level.
That would provide 99.999% of the target benefit

Unfortunately, it doesn't bring any of the benefits to static analysis that
Nikita is proposing. Indeed, it relies on existing static analysers
correctly finding the function definition to complain whether the optional
& is in place.

Including it as optional would certainly bring some benefit to readers, but
I think it's a lot less than "99.999%" of what making it mandatory would
bring.

Regards,

Rowan Collins
[IMSoP]

Le mar. 30 juil. 2019 à 10:34, Rowan Collins rowan.collins@gmail.com a
écrit :

On Tue, 30 Jul 2019 at 07:14, Nicolas Grekas nicolas.grekas@gmail.com
wrote:

I think enough time has passed since php4's call-by-ref for the syntax to
be
reused now. I think it's unfair to call the RFC a reminiscent of
call-by-ref BTW.

Firstly, please let's stop calling this a "PHP 4" feature. It was fully
supported right up to 5.2, deprecated in 5.3, and only removed in 5.4.

Secondly, I completely disagree that it's unfair to compare the two. The
syntax being proposed in this RFC (& at both call-site and definition-site)
was supported by versions prior to PHP 5.4. Those versions left it optional
at either side, which was certainly a mistake; but it was perfectly
possible (and probably common) for coding standards to require it in both
locations.

It might be a good idea to include a more thorough discussion of this
history in the RFC.

Call-time pass-by-reference is deprecated since PHP 4.3.0 and triggers a
deprecation warning since then:
https://3v4l.org/MFXsJ

That's since Dec 2002.

On Tue, 30 Jul 2019 at 10:00, Nicolas Grekas nicolas.grekas+php@gmail.com
wrote:

Call-time pass-by-reference is deprecated since PHP 4.3.0 and triggers a
deprecation warning since then:
https://3v4l.org/MFXsJ

That's since Dec 2002.

It looks like the history is more complicated than either of us are
remembering.

I based my assertion on the migration notes for PHP 5.3 [1] which simply
say:

Call-time pass-by-reference is now deprecated.

However, that looks to have been the result of an RFC [2] which gave more
background. According to that page, it's actually a PHP 3 feature, retained
through PHP 4 and PHP 5, with an option to disable it (at the time of that
RFC, there was still going to be a PHP 6). But since no warning was issued
if you left the option in its default state, most users had no idea that it
was considered deprecated, and carried on using it.

So the first time many people heard that they needed to stop marking their
call sites was PHP 5.3, released in 2009 and EOL in August 2014.

[1] https://www.php.net/manual/en/migration53.deprecated.php
[2] https://wiki.php.net/rfc/calltimebyref

Regards,

Rowan Collins
[IMSoP]

On Mon, Jul 29, 2019 at 5:35 PM Rowan Collins rowan.collins@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).

Something like that could in principle address the problem, though it would
enforce certain design decisions to allow reaching that eventual state. I
think this is how out/inout would have to work in order to satisfy BC
concerns while still allowing a declare-based mode that eliminates plain
by-ref passing entirely:

• All current by-ref parameters in extensions must be changed to out/inout
  parameters.
• By default, an out/inout parameter will behave exactly like a reference
  parameter and there is no behavioral difference between out/inout.
• Additionally, the call-site is allowed to specify out/inout. If it is
  specified, it must match the parameter. If it is specified, inout will
  generate a notice if the passed value doesn't exist (while out behaves as
  usual reference pass).
• A declare() exists that would require require call-site out/inout
  annotations and prohibit calls with reference parameters (that have not
  been converted to out/inout).
• Additional changes to type-checking for out/inout parameters in userland
  functions.

One migration problem that would still exist is that 3rd-party libraries
would also have to migrate to out/inout parameters first, before users
could enable the declare() mode that disables reference-passing --
otherwise they would not be able to make use of some of the library
functionality, or would have to opt-out in parts of the code. Alternatively
one could allow the use of out/inout with normal reference parameters as
well, in which case both out/inout would be allowed at the call-site.

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.

This kind of goes both ways: There is such a thing as "good enough" and
there's also the typical effect that going from a 95% solution to a 99%
solution will often take many times more effort (what's the technical term
for this?) In this context, "effort" isn't even the right word, it's a
combination of initial implementation effort, long-term maintenance cost
and possibly most importantly, language semantic complexity.

Above, I have outlined a way in which out/inout could work while mostly
addressing my original motivation. But is this approach really better than
a simple call-site "&" annotation that flawlessly integrates into the
existing reference passing system? I'm not convinced that it is. Especially
if we need to introduce out/inout in a way that interoperates well with
references for BC/migration purposes, the semantics become fairly complex,
while (imho) not offering a lot of benefit over a simple by-reference pass.
The main benefit I see would be an opportunity to fix the current
interaction of references and type annotations.

Every time I have discussed out/inout with people before, it has been in
the context of "What would we have to do to completely remove references?"
A large part of that is finding an alternative to by-reference passing that
does not use references. Hack introduced inout parameters (see
https://hhvm.com/blog/2018/03/15/hhvm-3.25.html) specifically to avoid the
issues of reference-passing (and they behave essentially like the
desugaring I mentioned in some earlier mail). But we would not get these
benefits using the approach outlined above, and I don't believe we could
use something significantly different while still supporting existing
by-ref internal functions.

This is why I don't think these two things should be mixed. Proper
out/inout parameters should not have anything to do with references.

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".

Right, references in arrays and objects are a pretty big WTF factor
(especially in how they behave with copying an cloning), but I don't really
have a good answer to those.

Regards,
Nikita

On Tue, Jul 30, 2019 at 11:01 AM Nicolas Grekas <
nicolas.grekas+php@gmail.com> wrote:

Le mar. 30 juil. 2019 à 10:34, Rowan Collins rowan.collins@gmail.com a
écrit :

On Tue, 30 Jul 2019 at 07:14, Nicolas Grekas nicolas.grekas@gmail.com
wrote:

I think enough time has passed since php4's call-by-ref for the syntax
to
be
reused now. I think it's unfair to call the RFC a reminiscent of
call-by-ref BTW.

Firstly, please let's stop calling this a "PHP 4" feature. It was fully
supported right up to 5.2, deprecated in 5.3, and only removed in 5.4.

Secondly, I completely disagree that it's unfair to compare the two. The
syntax being proposed in this RFC (& at both call-site and
definition-site)
was supported by versions prior to PHP 5.4. Those versions left it
optional
at either side, which was certainly a mistake; but it was perfectly
possible (and probably common) for coding standards to require it in both
locations.

It might be a good idea to include a more thorough discussion of this
history in the RFC.

Call-time pass-by-reference is deprecated since PHP 4.3.0 and triggers a
deprecation warning since then:
https://3v4l.org/MFXsJ

That's since Dec 2002.

Disclaimer: I started using PHP somewhere around PHP 5.2 times and have
never encountered call-time pass-by-reference as anything but a historical
concern, so I'm finding it somewhat hard to empathize with the associated
emotional baggage the issue may have.

With that in mind, I don't see an issue with reusing the previous call-time
pass-by-ref syntax here. The & at the call-site still means that the value
is going to be passed by refrence (or error), so it's not like someone who
was around during the call-time pass-by-ref times would misunderstand what
the code does based on their prior knowledge.

The only concern I see here is the emotional issue: Bringing & back as a
call-site annotation is an admission that the original migration of by-ref
passing has been badly botched: Yes, you removed those & at the call-site
for nothing. Yes, you shouldn't have been forced to do that!

Mistakes happen and hindsight is 20/20. But we should own up to those
mistakes.

Regards,
Nikita

With that in mind, I don't see an issue with reusing the previous
call-time pass-by-ref syntax here. The & at the call-site still means that
the value is going to be passed by refrence (or error), so it's not like
someone who was around during the call-time pass-by-ref times would
misunderstand what the code does based on their prior knowledge.

The only concern I see here is the emotional issue: Bringing & back as a
call-site annotation is an admission that the original migration of by-ref
passing has been badly botched: Yes, you removed those & at the call-site
for nothing. Yes, you shouldn't have been forced to do that!

Mistakes happen and hindsight is 20/20. But we should own up to those
mistakes.

I think that's a reasonable summary. Could you add a short section to the
RFC just acknowledging that history, and clarifying that this functionality
is effectively a subset of the previously removed feature, but without its
problems?

You're right that it's more of an emotional reaction than a rational one,
and shouldn't necessarily be a show-stopper IF we agree the proposed
behaviour is a big enough gain.

Regards,

Rowan Collins
[IMSoP]

I'm sorry Stas, but I will not be reading your mails in the future. I
think you mean
well and do raise legitimate points, but I have noticed over a long
period of time
that I find arguing with you to be extremely mentally exhaustive, while
ultimately deriving very little actionable benefit from these
discussions. You just
rub me entirely the wrong way. That's ultimately my own personal issue,
but I
don't think I can avoid acting on it any longer. I hope your position is
sufficiently
well-represented by other people.

Nikita,

I'm sorry, but that is completely unacceptable. I'm another person with
whom you used this approach in practice (and said as much, twice), even if
you didn't go quite as far as saying that it will be your ongoing policy
(and ignored my feedback on this). While disregarding a person's opinion
(especially one that's a core contributor) is unacceptable by itself - it's
even worse since claiming that "others will represent the position" is
playing make-belief. The reality (based on track record) is that you very
much tend to simply ignore strong & well-reasoned opposition to your
proposals. This has no place on internals.

If you can't thoroughly discuss the merits and issues of your proposals,
don't propose. Better yet - if you think that a proposal coming from you
is likely to result in a discussion that will mentally exhaust you - don't
propose it. It probably means it's far outside consensus and has no place
in PHP.

Regards,

Zeev

Both Zeev and Stas have long histories of poor behaviour, so for Zeev to
call out Nikita for choosing to ignore Stas is... funny.

I think ignoring people is totally acceptable behaviour on this list. May I
remind you that in the not distant past this list was called a toxic
kindergarten and other similar names by former and current contributors?
Simce we have little policy on ejecting toxic contributors, ignoring people
is the only way to keep sanity.

On Tue, Jul 30, 2019 at 6:10 PM Levi Morrison morrison.levi@gmail.com
wrote:

I think ignoring people is totally acceptable behaviour on this list. May I

remind you that in the not distant past this list was called a toxic
kindergarten and other similar names by former and current contributors?
Simce we have little policy on ejecting toxic contributors, ignoring people
is the only way to keep sanity.

It is not acceptable, period. If we need to pull rank with group@ here,
we will.

Zeev

Am 30.07.2019 um 17:14 schrieb Zeev Suraski zeev@php.net:

On Tue, Jul 30, 2019 at 6:10 PM Levi Morrison morrison.levi@gmail.com
wrote:

I think ignoring people is totally acceptable behaviour on this list. May I

remind you that in the not distant past this list was called a toxic
kindergarten and other similar names by former and current contributors?
Simce we have little policy on ejecting toxic contributors, ignoring people
is the only way to keep sanity.

It is not acceptable, period. If we need to pull rank with group@ here,
we will.

Zeev

You can either silently ignore somebody or announce it. You may consider it a courtesy to have it announced so that they don't wonder why they are not being replied to.
For me it's perfectly fine. Sure I wouldn't be happy if anyone said that about me, but I would have to accept it.
Everyone is free on his own who to listen to and who to ignore.

It's not up to you alone whether it's acceptable. Maybe it isn't for you. You're free to say that. But it's definitely not up to you to threaten, as an individual, with "group@". You are not a "we".

I'd appreciate if, now and in future, you would respect everyones free will in that regard;
thanks,
Bob

Hi!

You can either silently ignore somebody or announce it. You may
consider it a courtesy to have it announced so that they don't wonder
why they are not being replied to. For me it's perfectly fine. Sure I
wouldn't be happy if anyone said that about me, but I would have to
accept it. Everyone is free on his own who to listen to and who to
ignore.

You are completely free to ignore or not ignore anything you like. What
is not acceptable is driving sweeping changes in PHP language while
ignoring feedback from other members of the project. If you do not
intend to work with others, that's fine, don't - but then it can not be
a part of the community process. At least if we still want to have
a community and not just a bunch of people committing changes whenever
they feel like.

--
Stas Malyshev
smalyshev@gmail.com

Am 30.07.2019 um 17:14 schrieb Zeev Suraski zeev@php.net:

Zeev

Before I answer on point - I'd like to thank you that despite the fact you
clearly disagree with me - you wrote your message in a courteous,
respectful tone.

And now, on point:

You can either silently ignore somebody or announce it.

They're both unacceptable, when the feedback is on point - even if you (the
figurative 'you') completely disagree with it.

You may consider it a courtesy to have it announced so that they don't
wonder why they are not being replied to.

There's absolutely nothing courtesous about it. Both behaviors - silent
ignorance and announced ignorance - are rude. It's debatable which one is
worse - but they're both unacceptable.

Everyone is free on his own who to listen to and who to ignore.

Not everyone. Not people that are requesting comments on their proposals.
There's a reason we call RFCs RFCs.

Folks who decide to move on with the challenging and tedious process of
changing the language, MUST be willing to do what it takes. And it
absolutely means defending their proposal, including from folks who may
have issues with them.

If you're not up for it, do not propose. If you propose, be ready to
discuss it in good faith, including with folks with opposing views who take
their time to write detailed feedback. It doesn't matter if you know
there's no way you will be convinced, or that the other party will be
convinced. That discussion is extremely relevant for everyone else who is
supposed to make up their mind about the proposal.

It's not up to you alone whether it's acceptable. Maybe it isn't for you.

You're free to say that. But it's definitely not up to you to threaten,
as
an individual, with "group@". You are not a "we".

I'm confident that if it ever came to that, I'll have the backing of group@
,
which is why I wrote what I wrote. Perhaps the statement wasn't properly
wordsmithed, but that's what I meant.
Ignoring on-point feedback - from top contributors, no less - is so much
contrary to the spirit on which this project has been based, that it's a no
brainer no-no.

I'd appreciate if, now and in future, you would respect everyones free
will in that regard;

The free will plays a role in one's decision to move forward or not move
forward witha proposal. If they do - it's absolutely their responsibility
to defend their proposal if & when folks scrutinize it and find issues with
it. That's why we have a long, mandatory discussion period. Opting out is
not an option.

On a partially related note, I think there might be a more comprehensive
solution to polarization we're all (or at least many of us) are suffering
from in terms of the language's direction, one that may make both camps
happy, without turning every RFC into a contentious fight (and not by
updating our rules, but by changing what we offer). I'll spend some time
thinking about it and propose it when it matures a bit, hopefully next
week.

Zeev,

I am putting myself at a disadvantage here. I am not suppressing Stas'
voice, only removing my own ability to argue against it, and effectively
strengthening its position. Everyone else can still see his arguments and
be swayed by them. If they're good arguments and well delivered, they will
be. If they aren't -- well, that's hardly my own fault.

I read RFC feedback and engage in discussions, because I want to deliver
the best proposal I can, which incidentally is also the most likely to be
accepted. However, not all forms of feedback are created equal. It is a
staple of polite debate that criticism be actionable -- it is not
sufficient to register your disapproval, you also need to suggest possible
avenues for improvement or alternative approaches that may be pursued.

If I have found that a particular source of feedback has, over many years,
been consistently and persistently negative and only on rare occasions
yielded an actionable insight, I believe it is my prerogative to remove
this source from my personal consideration, especially if it has a negative
influence on my mental well-being.

Regards,
Nikita

If you propose, be ready to discuss it in good faith, including
with folks with opposing views who take their time to write detailed feedback.

Some of the points raised during discussions are not technical
arguments that can be addressed, some of them are concerns about what
the development experience will be like. They are valid concerns but
it's impossible to give a definitive 100% non-criticisable response to
them.

It's not always possibly to convince everyone that an idea is going to
be a good idea.

This is why we have voting rather than consensus, so that after people
have said the things they want to say, we can have a vote and move
forward, rather than getting stuck and both sides trying to 'win' an
argument where people can have valid differences of opinion.

There's a reason we call RFCs RFCs.

Yes, so people can make comments on them, not that people have to win
over every voter.

And it absolutely means defending their proposal, including from
folks who may have issues with them.

If they do - it's absolutely their responsibility
to defend their proposal

Zeev, this isn't a rule that has been agreed.

If you wish to change the rules, to include the idea of having a
"long-term view" special committee or similar, please do propose that
as an RFC to be discussed. Or if you want some way of formally listing
"unaddressed concerns" in the RFC, that could also be discussed.

But making vague threats to try to influence other contributors is
completely inappropriate behaviour.

cheers
Dan
Ack

If you do not intend to work with others, that's fine, don't - but
then it can not be a part of the community process. At least
if we still want to have a community and not just a bunch
of people committing changes whenever they feel like.

I think this gets to the heart of the matter.

You and Zeev have disagreed with several RFCs that have passed, and
apparently you're perceiving that as "people committing changes
whenever they feel like".

People are not just committing changes whenever they feel like.

People are going through the RFC process, and only if the vote is
successful do things get merged.

People are free to vote based on whatever factors they like, and
having the RFC author not address some points that you think are
important should be on of those factors. And you're obviously free to
announce that you're voting no because you think some points haven't
been addressed, and that might influence how other people vote.

People choosing to not reply to every detail of negative feedback does
not mean they are "committing changes whenever they feel like".

That you're perceiving it as that, is a problem of perception on your
side, not something that can or should be fixed on the community side.

cheers
Dan
Ack

This was not a threat of any kind,

"If we need to pull rank with group@ here, we will."

"I'm confident that if it ever came to that, I'll have the backing of
group@, which is why I wrote what I wrote."

Those are threats.

You were threatening to have an ill-defined group of people force
changes in how RFCs are carried out.

Please don't make threats. And also don't make threats and then
pretend you're not making threats.

Even without reading Stas's messages in detail - their length alone suggests

"Their length alone."

"Their length alone".

This is why trying to force RFC authors to respond to every point is
such a bad idea.

It allows filibustering of RFCs by having people who are opposed to
the RFC by bringing up voluminous complaints. This is described nicely
in a video called "How Open Source Projects Survive Poisonous People
(And You Can Too)" - https://www.youtube.com/watch?v=Q52kFL8zVoM which
I recommend everyone watch.

Zeev, both you and Stas seem to be making lots of noise due to some
RFCs having been passed despite your objections. The whole reason
voting for RFCs was introduced was so that progress could be made even
when some community members objected to an RFC.

If you want to change how the RFC process happens, to have a "long
term stability committee" or something similar, please raise an RFC
for it. But just making noise and threats on this list is completely
non-productive.

cheers
Dan
Ack

threat /THret/ noun: a statement of an intention to inflict pain,
injury, damage, or other hostile action on someone in retribution for
something done or not done.

Anyway, can we vote on this RFC?

This was not a threat of any kind,

"If we need to pull rank with group@ here, we will."

"I'm confident that if it ever came to that, I'll have the backing of
group@, which is why I wrote what I wrote."

Those are threats.

No Dan, they are not. You're remarkably offensive for claiming that - not
only based on your own initial misinterpretation, but also after I took the
time to explain[1]. Perhaps it has to do with a very bogus definition for
the word 'threat', by which one could consider every RFC as a threat as
well. It was a clear call to order. If you want to call it a threat, or
Coolio, or some other word - that is entirely up to you, but it does not
change the fact that it wasn't a threat.

Zeev

[1] "This was not a threat of any kind, and framing it as such is
inappropriate by itself. I wasn't "threatening" to have anyone kicked or
otherwise penalized. It was a reminder of one of the ground rules -
respectful discussion and focusing on the ideas and not the people they
came from - and making it clear I have no intention to yield on it. I said
that if for some reason what has been and should continue to be obvious -
just as much as the discussions here have to be respectful (and in English)

• is no longer obvious - we'll make it clear. That's all."

--
Guilherme Blanco
SVP Technology at Statflo Inc.
Mobile: +1 647 232 5599

Hi!

This is why trying to force RFC authors to respond to every point is
such a bad idea.

You try to absurdize the position by taking it to unreasonable absolute.
Nobody asks anybody to respond to literally every point, no matter how
minor. Responding on major objections, however, is expected.

It allows filibustering of RFCs by having people who are opposed to
the RFC by bringing up voluminous complaints. This is described nicely
in a video called "How Open Source Projects Survive Poisonous People
(And You Can Too)" - https://www.youtube.com/watch?v=Q52kFL8zVoM which
I recommend everyone watch.

It is kinda insulting to be called "poisonous" because I try to argue my
position and explain my argument. I guess I should limit myself to "this
RFC sucks #noway" and we can move our discussions to Twitter.

But then I notice there's no objection to the quality of my argument.
Only that's it too hard to read it, apparently, because it requires
effort. I am astonished that this is a serious complaint...

Zeev, both you and Stas seem to be making lots of noise due to some
RFCs having been passed despite your objections. The whole reason
voting for RFCs was introduced was so that progress could be made even
when some community members objected to an RFC.

Again, there's a difference between majority and minority disagreeing
and plainly ignoring major objections that will have large detrimental
effect on the user base (which BTW can not vote). Sure, a shiny syntax
addition could be voted in while most of the voters not realizing
subtler problems it would bring - how is it a good thing?
Voting is only a part of the RFC process. It we have vote and no
discussion, that turns into popularity contest and political game, which
is no way to run a technical project. Technical discussion is a vital
part of the RFC process.

If you want to change how the RFC process happens, to have a "long
term stability committee" or something similar, please raise an RFC
for it. But just making noise and threats on this list is completely
non-productive.

Calling other person's arguments "noise" kinda describes how seriously
you intend to treat them.

Stas Malyshev
smalyshev@gmail.com

Hi!

You and Zeev have disagreed with several RFCs that have passed, and
apparently you're perceiving that as "people committing changes
whenever they feel like".

Please, for the love of all that is holy, do not try to guess what I
think. You are bad at it. I never claimed that, never thought that and
my argument was not about that. My argument is about that technical
discussion is vital to informed vote, and withdrawing from it and saying
"TLDR, okthxbye, see you at the voting!" is not the right way to conduct
RFC process, even if technically it has all the signs of the proper
process - discussion, response, voting, etc.

People are not just committing changes whenever they feel like.

I know. And I want to keep it this way. The way to do it is to keep
proper RFC process.

--
Stas Malyshev
smalyshev@gmail.com