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

  101254
December 6, 2017 19:49 nikita.ppv@gmail.com (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
  101255
December 6, 2017 20:08 lists@rhsoft.net ("lists@rhsoft.net")
Am 06.12.2017 um 20:49 schrieb Nikita Popov:
> 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
IMHO a bad idea after "PHP Fatal error: Call-time pass-by-reference has been removed" not that long ago which was exactly the same syntax https://stackoverflow.com/questions/8971261/php-5-4-call-time-pass-by-reference-easy-fix-available https://stackoverflow.com/questions/18046846/why-is-function-call-by-reference-in-php-deprecated
  101256
December 6, 2017 21:11 pollita@php.net (Sara Golemon)
On Wed, Dec 6, 2017 at 2:49 PM, Nikita Popov ppv@gmail.com> wrote:
> 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. > The way I understand this, it only provides a readability hint for the
human, yes? As far as the compiler is concerned, you're either confirming what it already knows, or it's throwing an error because what you think will be pass-by-ref, won't be. I'm not strictly against it in terms of helping readability for humans, but that kind of information can also live in a docblock with nearly the same force and effect (modulo the warning when the hint is wrong). -Sara
  101257
December 6, 2017 21:14 pollita@php.net (Sara Golemon)
On Wed, Dec 6, 2017 at 4:11 PM, Sara Golemon <pollita@php.net> wrote:
>... that kind of information can also live in a docblock with > nearly the same force and effect (modulo the warning when the hint is > wrong). > Sorry, ignore that last statement. I've got a weird headache going on atm.
Still neutral on it either way. Yay for readability by humans, I guess. -Sara
  101258
December 6, 2017 21:31 rowan.collins@gmail.com (Rowan Collins)
On 06/12/2017 19:49, Nikita Popov wrote:
> 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
Hi Nikita, I approve of the aims of this proposal, but I do wonder if it would be a bit awkward to reuse the syntax which people had to spend so much effort removing in PHP 5.4 (you refer to it as a PHP 4 feature, but for many people it's a much more recent memory). Aside from the frustration of "why didn't we allow it in these cases all along", I can see people being confused if it went from OK to fatal error to encouraged and maybe even mandatory. Your future scope section mentions having more explicit "out" and "inout" annotations; perhaps it would be better to skip ahead to these, with new syntax, and more immediate benefits all round. Is there a reason we can't do this right now? I imagine these working like the & annotation, with the following extra rules: 1) Parameters marked "out" or "inout" in function definitions MUST also be marked "out" or "inout" in calls to that function. 2) Parameters marked "&" in function definitions MAY be marked with "out" or "inout" in calls to that function. 3) A variable passed to an "inout" parameter would raise a notice if it was not defined before use, since it should have a value for the "in" part. 4) A variable passed to an "out" parameter would NOT raise such a notice, since the function call would be a valid initialisation. 5) An already-initialised variable passed to an "out" parameter would be set to null before calling the function. If the function never assigned to it, it would remain null in the calling scope. Rule 2 allows for better interoperability between old and new code, and I am imagining it also applying to core functions, so that this would work without pre-initialising $matches: preg_match($pattern, $string, out $matches); I'm not sure how reference-returning functions fit into this picture, and there are probably other kinks to iron out, but it seems like it would have a lot more benefits overall. Regards, -- Rowan Collins [IMSoP]
  101259
December 6, 2017 21:41 dave+php@mudsite.com (David Walker)
On Wed, Dec 6, 2017 at 2:32 PM Rowan Collins collins@gmail.com>
wrote:

> On 06/12/2017 19:49, Nikita Popov wrote: > > 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 > > > Hi Nikita, > > I approve of the aims of this proposal, but I do wonder if it would be a > bit awkward to reuse the syntax which people had to spend so much effort > removing in PHP 5.4 (you refer to it as a PHP 4 feature, but for many > people it's a much more recent memory). Aside from the frustration of > "why didn't we allow it in these cases all along", I can see people > being confused if it went from OK to fatal error to encouraged and maybe > even mandatory. > > Your future scope section mentions having more explicit "out" and > "inout" annotations; perhaps it would be better to skip ahead to these, > with new syntax, and more immediate benefits all round. Is there a > reason we can't do this right now? > > I imagine these working like the & annotation, with the following extra > rules: > > 1) Parameters marked "out" or "inout" in function definitions MUST also > be marked "out" or "inout" in calls to that function. > 2) Parameters marked "&" in function definitions MAY be marked with > "out" or "inout" in calls to that function. > 3) A variable passed to an "inout" parameter would raise a notice if it > was not defined before use, since it should have a value for the "in" part. > 4) A variable passed to an "out" parameter would NOT raise such a > notice, since the function call would be a valid initialisation. > 5) An already-initialised variable passed to an "out" parameter would be > set to null before calling the function. If the function never assigned > to it, it would remain null in the calling scope. > > Rule 2 allows for better interoperability between old and new code, and > I am imagining it also applying to core functions, so that this would > work without pre-initialising $matches: preg_match($pattern, $string, > out $matches); > > I'm not sure how reference-returning functions fit into this picture, > and there are probably other kinks to iron out, but it seems like it > would have a lot more benefits overall. > > Regards,
Hi Nikita, I'd be more hesitant about seeing this syntax re-introdouced. Having recently been through the process of spending days to remove all the call-time by-reference fatals. Especially when the syntax proposed is generally ignored (excepting in the has &, but declaration doesn't). I do like the C-esque feel of having the declaration require a reference, and the call-side provide the reference, but the RFC lacks the warning where the declaration has reference, but call-side lacks it. However, adding this warning would probably anger everyone who did spend the time to remove all the call-time references only to now add them back in. I'd be with Rowan here. If the language is going to re-introduce old syntax as purely a visual aid, it would probably behoove us to actually look at the in/inout/out parameter types. I would be way more excited to see that play out, than having call-time-reference brought back. Cheers, -- Dave
  101260
December 7, 2017 02:04 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> 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.
We had usage of this syntax for similar, but different purpose before it was removed. Reinstating it now would be confusing, and generally not a good practice - having one syntax mean different things in different PHP versions is not good. It is not likely that we'd ever want to make it mandatory, due to the overwhelming mass of code relying on the current syntax, and without it instead of making code more clear, it would make it more confusing - if & means by-ref, does absence of it mean by-value? Nope. So you still have to check. Unless of course you rework all existing code to add & - which would be rather hard and will make it incompatible with every currently supported version of PHP. All this to achieve no other benefit but a purely cosmetic one which a good IDE could easily deliver to you for free without changing language syntax. I do not think it is worth it. -- Stas Malyshev smalyshev@gmail.com
  101295
December 10, 2017 21:41 andreas@dqxtech.net (Andreas Hennings)
On 7 December 2017 at 03:04, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> > All this to achieve no other benefit but a purely cosmetic one which a > good IDE could easily deliver to you for free without changing language > syntax. I do not think it is worth it. >
I agree with Stanislav, this should be the IDE's job. PhpStorm can already show parameter name hints in function calls. It could easily add a feature to show if a parameter is by-reference. In fact I will request this as we speak :)
  101296
December 10, 2017 21:43 andreas@dqxtech.net (Andreas Hennings)
Oh wow, feature request already exists, with a link to this thread.

On 10 December 2017 at 22:41, Andreas Hennings <andreas@dqxtech.net> wrote:

> > > On 7 December 2017 at 03:04, Stanislav Malyshev <smalyshev@gmail.com> > wrote: >> >> All this to achieve no other benefit but a purely cosmetic one which a >> good IDE could easily deliver to you for free without changing language >> syntax. I do not think it is worth it. >> > > I agree with Stanislav, this should be the IDE's job. > > PhpStorm can already show parameter name hints in function calls. It could > easily add a feature to show if a parameter is by-reference. > In fact I will request this as we speak :) >
  101262
December 8, 2017 00:38 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Den 2017-12-06 kl. 20:49, 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 think this proposal has a good point about static analysers,
not just about human readability. A good static analyser is very helpful for eg migration projects and if this proposal benefits that, it's a plus. Also using same syntax for references like in other parts of the language has a value. Now expressing the same thing in two different ways, with or without & is confusing, so I think one needs to think about if old syntax should be deprecated in 8.0. Has never used PHP 4, so not confused by old PHP 4 syntax but I guess for people on this list the percentage is higher... r//Björn
  101263
December 8, 2017 01:54 lists@rhsoft.net ("lists@rhsoft.net")
Am 08.12.2017 um 01:38 schrieb Björn Larsson:
> Den 2017-12-06 kl. 20:49, 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. >> > I think this proposal has a good point about static analysers, > not just about human readability. > > A good static analyser is very helpful for eg migration projects > and if this proposal benefits that, it's a plus. Also using same > syntax for references like in other parts of the language has a > value. > > Now expressing the same thing in two different ways, with or > without & is confusing, so I think one needs to think about if > old syntax should be deprecated in 8.0
to get this consistent that would also require change every line of code calling core functions like sort instead of sort($array) as sort($array) i doubt that the benefits could justify the BC break
  101264
December 8, 2017 04:41 php-lists@koalephant.com (Stephen Reay)
> On 8 Dec 2017, at 08:54, "lists@rhsoft.net" <lists@rhsoft.net> wrote: > > > >> Am 08.12.2017 um 01:38 schrieb Björn Larsson: >>> Den 2017-12-06 kl. 20:49, 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. >>> >> I think this proposal has a good point about static analysers, >> not just about human readability. >> A good static analyser is very helpful for eg migration projects >> and if this proposal benefits that, it's a plus. Also using same >> syntax for references like in other parts of the language has a >> value. >> Now expressing the same thing in two different ways, with or >> without & is confusing, so I think one needs to think about if >> old syntax should be deprecated in 8.0 > > to get this consistent that would also require change every line of code calling core functions like sort instead of sort($array) as sort($array) > > i doubt that the benefits could justify the BC break > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
I think Rowan's suggestion makes a lot of sense. There's zero bc break for existing code, but new/updated code can get the benefits of being specific about how the parameter is used. I know "references are the wrong tool for any job" is a belief held my some of the community - I'm curious if out/inout parameters solve any of their concerns about references? Cheers Stephen
  101266
December 8, 2017 07:12 me@jhdxr.com (=?utf-8?b?Q0hVIFpoYW93ZWk=?=)
On Friday, December 8, 2017 12:42 PM, "Stephen Rea" < php-lists@koalephant.com> wrote:
>> On 8 Dec 2017, at 08:54, "lists@rhsoft.net" <lists@rhsoft.net> wrote: >> >> >> >>> Am 08.12.2017 um 01:38 schrieb Björn Larsson: >>>> Den 2017-12-06 kl. 20:49, 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. >>>> >>> I think this proposal has a good point about static analysers, not >>> just about human readability. >>> A good static analyser is very helpful for eg migration projects and >>> if this proposal benefits that, it's a plus. Also using same syntax >>> for references like in other parts of the language has a value. >>> Now expressing the same thing in two different ways, with or without >>> & is confusing, so I think one needs to think about if old syntax >>> should be deprecated in 8.0 >> >> to get this consistent that would also require change every line of >> code calling core functions like sort instead of sort($array) as >> sort($array) >> >> i doubt that the benefits could justify the BC break >> >> -- >> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, >> visit: http://www.php.net/unsub.php >> > >I think Rowan's suggestion makes a lot of sense. There's zero bc break for existing code, but new/updated code can get the benefits of being specific about how the parameter is used.
Agreed, and I think those BC break change will be fine if it targets 8.0. I know people always argue that it's stupid to break the working code, but IMHO it's ok for a major version update with good reason.
  101267
December 8, 2017 10:16 lists@rhsoft.net ("lists@rhsoft.net")
Am 08.12.2017 um 05:41 schrieb Stephen Reay:
> > >> On 8 Dec 2017, at 08:54, "lists@rhsoft.net" <lists@rhsoft.net> wrote: >> >> >> >>> Am 08.12.2017 um 01:38 schrieb Björn Larsson: >>>> Den 2017-12-06 kl. 20:49, 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. >>>> >>> I think this proposal has a good point about static analysers, >>> not just about human readability. >>> A good static analyser is very helpful for eg migration projects >>> and if this proposal benefits that, it's a plus. Also using same >>> syntax for references like in other parts of the language has a >>> value. >>> Now expressing the same thing in two different ways, with or >>> without & is confusing, so I think one needs to think about if >>> old syntax should be deprecated in 8.0 >> >> to get this consistent that would also require change every line of code calling core functions like sort instead of sort($array) as sort($array) >> >> i doubt that the benefits could justify the BC break > I think Rowan's suggestion makes a lot of sense. There's zero bc break for existing code, but new/updated code can get the benefits of being specific about how the parameter is used.
"Now expressing the same thing in two different ways, with or without & is confusing, so I think one needs to think about if old syntax should be deprecated in 8.0" would be a massive BC break and it's much bader to use a not so long existed syntax which was now changed to a fatal error - just type "php call-by-reference" in google
> I know "references are the wrong tool for any job" is a belief held my some of the community - I'm curious if out/inout parameters solve any of their concerns about references?
now because they are not bad because the syntax, they are bad fopr most usecases because you try to be smarter the PHP's copy-on-write but in most cases you won't
  101268
December 8, 2017 16:36 me@jhdxr.com ("=?utf-8?B?Q0hVIFpoYW93ZWk=?=")
On Fri, Dec 8, 2017 06:16 PM, "lists@rhsoft.net" <lists@rhsoft.net> wrote:
> >and it's much bader to use a not so long existed syntax which was now >changed to a fatal error - just type "php call-by-reference" in google > I know most people of this list using and contributing to PHP for a very long time, but I want to point out that the old "call-time pass-by-reference" was deprecated from php 5.3, which is more than 8 years ago. People with modern framework and tools are not troubled by the old and already removed syntax. The real trouble is I cannot figure out the parameter is passed by reference or value unless I go to the defination of the method.
btw, I really googled "php call-by-reference", the latest page was post on 2012, 5 years ago.
>> I know "references are the wrong tool for any job" is a belief held my some of the community - I'm curious if out/inout parameters solve any of their concerns about references? > >now because they are not bad because the syntax, they are bad fopr most >usecases because you try to be smarter the PHP's copy-on-write but in >most cases you won't If you point is pass-by-reference is bad and stupid, then it's off-topic and I suggest you should create a new RFC to abandon this feature. This RFC is aimed at making things more clear for developers and static analyzers.
  101270
December 8, 2017 16:56 lists@rhsoft.net ("lists@rhsoft.net")
Am 08.12.2017 um 17:36 schrieb CHU Zhaowei:
> On Fri, Dec 8, 2017 06:16 PM, "lists@rhsoft.net" <lists@rhsoft.net> wrote: > > > >and it's much bader to use a not so long existed syntax which was now > >changed to a fatal error - just type "php call-by-reference" in google > > > I know most people of this list using and contributing to PHP for a very > long time, but I want to point out that the old "call-time > pass-by-reference" was deprecated from php 5.3, which is more than 8 > years ago
but PHP 5.4 where it changed ot be a fatal error is not that long ago and will live many years because it's part of RHEL7
> People with modern framework and tools are not troubled by > the old and already removed syntax. The real trouble is I cannot figure > out the parameter is passed by reference or value unless I go to the > defination of the method. > btw, I really googled "php call-by-reference", the latest page was post > on 2012, 5 years ago.
you can not because people don't use proper comments myfunction /**&$var*/$x);
> If you point is pass-by-reference is bad and stupid, then it's off-topic > and I suggest you should create a new RFC to abandon this feature. This > RFC is aimed at making things more clear for developers and static > analyzers
my main point was that if you don't make it mandatory it's worth nothing and if you make it mandatory you need to bew aware that this not only affects in PHP written function but also all calls to internal functions which work wit references like sort() and so *a lot* of code written in PHP needs to be touched FRANKLY: if you re-use the syntax and make it mandatoty it's terrible while adopt code because all your existing code won't work with the next PHP version and every adopted line no longer works with the current version because it throws fatal errors you also need to consider adoption of a future PHP version which likely get a heavy impact with syntax changes where the same code has two different meanings while both throw fatal errors in a older or in the next one ________________________ to make things clearer for developers comments where invented - see above - and that most php developers don't wirte well commented and readable code is a completly different story static analyzers - well, i need yet to see one really useable for PHP code, but that#s also a different story the real issue: if the long plan is to make the call syntax mandarory it still should not re-use a syntax which was deprecated and removed years ago because the fact you will find tons of stuff refer to the old one it should really use something else and no re-use
  101271
December 8, 2017 17:55 php-lists@koalephant.com (Stephen Reay)
> On 8 Dec 2017, at 5:16 pm, lists@rhsoft.net wrote: > > "Now expressing the same thing in two different ways, with or without & is confusing, so I think one needs to think about if old syntax should be deprecated in 8.0" would be a massive BC break
That wasn’t in Rowans suggestion, it was in Björn’s response to the original message. You’re either not reading who wrote what before you reply, or you’re deliberately trying to imply a person has advocated for something they never even mentioned. Even *if* the consensus was to drop support for & references in php8 - thats a major new version, with AFAIK, literally no planned ETA, of any kind.
  101272
December 9, 2017 02:15 lists@rhsoft.net ("lists@rhsoft.net")
Am 08.12.2017 um 18:55 schrieb Stephen Reay:
>> On 8 Dec 2017, at 5:16 pm, lists@rhsoft.net <mailto:lists@rhsoft.net> >> wrote: >> >> "Now expressing the same thing in two different ways, with or without >> & is confusing, so I think one needs to think about if old syntax >> should be deprecated in 8.0" would be a massive BC break > > That wasn’t in Rowans suggestion, it was in Björn’s response to the > original message. You’re either not reading who wrote what before you > reply, or you’re deliberately trying to imply a person has advocated for > something they never even mentioned.
i responded to Björn's response and when someone than quotes me and refer to a side thread i am really not guilty
> Even *if* the consensus was to drop support for & references in php8 - > thats a major new version, with AFAIK, literally no planned ETA, of any > kind
besides that's not the topic at all and i just responded to "If you point is pass-by-reference is bad and stupid, then it's off-topic and I suggest you should create a new RFC to abandon this feature" however, "that's a major new version" is completly irrelevant in this point of time - what is relevant to think about the outcome of whatever is suggested *long before* something is even seriously considered to make things right - with the least possible BC break unless it is justified by a major benefit which makes the break worth that's somehow learning from past mistakes and avoid to repeat them in similar changes - if such discussions would have happened always before consider implementations we would not sit here with similar functions but reverse parameter order and other such "nice" things which are ugly but fix them now would introduce a lot of more troubles than it solves
  101293
December 10, 2017 13:12 johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)
Hi,

On Mi, 2017-12-06 at 20:49 +0100, Nikita Popov wrote:
> 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 >
I would rather discourage usage of references. Since PHP 7 the cost of breaking cow isn't as expensive anymore, but receiving values by value and returning by value is more idiomatic imo. Using objects can be more efficient. johannes
  101328
December 12, 2017 06:38 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> I would rather discourage usage of references. Since PHP 7 the cost of > breaking cow isn't as expensive anymore, but receiving values by value > and returning by value is more idiomatic imo. Using objects can be more > efficient.
Objects are kind of overkill when you just need a modifyable array. And copying an array when you just need to add one value to a K-size array is still not a good idea for many apps. O(n) vs O(n^2) still matters. One should definitely be careful not to overuse refs, but there are still valid cases for using them. -- Stas Malyshev smalyshev@gmail.com
  101330
December 12, 2017 07:43 johannes@schlueters.de (=?ISO-8859-1?Q?Johannes_Schl=FCter?=)
On December 12, 2017 7:38:54 AM GMT+01:00, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>Hi! > >> I would rather discourage usage of references. Since PHP 7 the cost >of >> breaking cow isn't as expensive anymore, but receiving values by >value >> and returning by value is more idiomatic imo. Using objects can be >more >> efficient. > >Objects are kind of overkill when you just need a modifyable array. And >copying an array when you just need to add one value to a K-size array >is still not a good idea for many apps. O(n) vs O(n^2) still matters. >One should definitely be careful not to overuse refs, but there are >still valid cases for using them.
The issue, as you well know, is that references disable copy-on-write. Thus assume you have code like this: function with_ref(&$a) { count ($a); } function no_ref($a) { count($a); } The count in with_ref() will copy the array, while no_ref() can use copy on write and won't actually copy. johannes
  101332
December 12, 2017 07:51 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> The issue, as you well know, is that references disable copy-on-write. Thus assume you have code like this: > > function with_ref(&$a) { > count ($a); > } > > function no_ref($a) { > count($a); > } > > The count in with_ref() will copy the array, while no_ref() can use copy on write and won't actually copy.
Yes, this is an issue, and it'd be good to find a way to solve it. At least for count() and other "pure" (however pure can it be in PHP) functions it seems possible. But do not think "not using references ever" qualifies as a solution :) -- Stas Malyshev smalyshev@gmail.com
  101333
December 12, 2017 08:16 johannes@schlueters.de (=?ISO-8859-1?Q?Johannes_Schl=FCter?=)
On December 12, 2017 8:51:42 AM GMT+01:00, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>Hi! > >> The issue, as you well know, is that references disable >copy-on-write. Thus assume you have code like this: >> >> function with_ref(&$a) { >> count ($a); >> } >> >> function no_ref($a) { >> count($a); >> } >> >> The count in with_ref() will copy the array, while no_ref() can use >copy on write and won't actually copy. > >Yes, this is an issue, and it'd be good to find a way to solve it. At >least for count() and other "pure" (however pure can it be in PHP) >functions it seems possible. But do not think "not using references >ever" qualifies as a solution :)
For this case there is a good solution: Let the engine be smart and pass by value :-D And yes there are a few cases where references might be better: Graph like structures (while I'd claim objects are nicer, but that's subjective), capturing by-ref in closures (`use` clause, while many times an object to hold state can be, subjectively, better, but sometimes you just need a counter or such) and returning error codes by-ref (if objects or exceptions aren't better, this most often is more low-level stuff, i.e. in json_decode() I'd see benefits over json_error_last()) Some years back I spent quite some time with different cases almost always removing the references gave faster and clearer code (while this proposal to add & to the call sign takes away some wtf) not only in my opinion, but also the respective maintainers. Of course with PHP 7 the maths changed a bit, but fundamentally I stand by my opinion. johannes
  101335
December 12, 2017 13:45 nikita.ppv@gmail.com (Nikita Popov)
On Tue, Dec 12, 2017 at 8:43 AM, Johannes Schlüter <johannes@schlueters.de>
wrote:

> > > On December 12, 2017 7:38:54 AM GMT+01:00, Stanislav Malyshev < > smalyshev@gmail.com> wrote: > >Hi! > > > >> I would rather discourage usage of references. Since PHP 7 the cost > >of > >> breaking cow isn't as expensive anymore, but receiving values by > >value > >> and returning by value is more idiomatic imo. Using objects can be > >more > >> efficient. > > > >Objects are kind of overkill when you just need a modifyable array. And > >copying an array when you just need to add one value to a K-size array > >is still not a good idea for many apps. O(n) vs O(n^2) still matters. > >One should definitely be careful not to overuse refs, but there are > >still valid cases for using them. > > The issue, as you well know, is that references disable copy-on-write. > Thus assume you have code like this: > > function with_ref(&$a) { > count ($a); > } > > function no_ref($a) { > count($a); > } > > The count in with_ref() will copy the array, while no_ref() can use copy > on write and won't actually copy.
This is no longer the case as of PHP 7. PHP 7 can share values between references and non-references. Nikita
  101346
December 13, 2017 05:01 pollita@php.net (Sara Golemon)
On Tue, Dec 12, 2017 at 2:43 AM, Johannes Schlüter
<johannes@schlueters.de> wrote:
> The issue, as you well know, is that references disable copy-on-write. Thus assume you have code like this: > > function with_ref(&$a) { > count ($a); > } > > function no_ref($a) { > count($a); > } > > The count in with_ref() will copy the array, while no_ref() can use copy on write and won't actually copy. > That *was* true in PHP 5.
In PHP 7, the with_ref() version has a very slight overhead boxing the array into an IS_REF zval, then unboxing it for the call to count(). This isn't a deep (or even shallow) copy. It's one extra zval alloc and a few integer ops. -Sara
  101300
December 11, 2017 02:29 levim@php.net (Levi Morrison)
On Wed, Dec 6, 2017 at 12:49 PM, Nikita Popov ppv@gmail.com> wrote:
> 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 think we ought to commit to requiring the ampersand at the call site some point in the future. As others have noted it provides little benefit at the call site if it is not required. However, there is an area where this does provide value that others have not yet mentioned or thought of: `callable` parameters. public function apply(callable $f) { return $f(&$this->data); } This requires the callable to accept the argument by reference, something we cannot currently require. Of course this is rarely needed; I am merely pointing out this feature is more than a syntactic hint to humans. Based on the current discussion I would vote yes on this RFC, despite the concerns raised by others.
  101414
December 24, 2017 16:45 ajf@ajf.me (Andrea Faulds)
Hi Levi,

Levi Morrison wrote:
> On Wed, Dec 6, 2017 at 12:49 PM, Nikita Popov ppv@gmail.com> wrote: >> 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 think we ought to commit to requiring the ampersand at the call site > some point in the future. As others have noted it provides little > benefit at the call site if it is not required. > > However, there is an area where this does provide value that others > have not yet mentioned or thought of: `callable` parameters. > > public function apply(callable $f) { > return $f(&$this->data); > } > > This requires the callable to accept the argument by reference, > something we cannot currently require. Of course this is rarely > needed; I am merely pointing out this feature is more than a syntactic > hint to humans. > > Based on the current discussion I would vote yes on this RFC, despite > the concerns raised by others. >
Perhaps more useful is the inverse: in future, we could require that a callable *not* take a value by-reference unless the caller asks for it. That would prevent potential monkeying with the scope of the caller by the callee — if right now you do $f($this->data), you might forget that $f could take that parameter by reference and gain the ability to modify that variable indefinitely… Thanks -- Andrea Faulds https://ajf.me/
  106292
July 25, 2019 12:32 nikita.ppv@gmail.com (Nikita Popov)
On Wed, Dec 6, 2017 at 8:49 PM Nikita Popov ppv@gmail.com> wrote:

> 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
  106293
July 25, 2019 13:01 george.banyard@gmail.com ("G. P. B.")
On Thu, 25 Jul 2019 at 14:32, Nikita Popov ppv@gmail.com> wrote:

> On Wed, Dec 6, 2017 at 8:49 PM Nikita Popov ppv@gmail.com> wrote: > > > 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
  106294
July 25, 2019 13:14 rowan.collins@gmail.com (Rowan Collins)
On Thu, 25 Jul 2019 at 13:32, Nikita Popov ppv@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". (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]
  106296
July 25, 2019 13:48 nikita.ppv@gmail.com (Nikita Popov)
On Thu, Jul 25, 2019 at 3:14 PM Rowan Collins collins@gmail.com>
wrote:

> On Thu, 25 Jul 2019 at 13:32, Nikita Popov ppv@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
  106297
July 25, 2019 14:40 rowan.collins@gmail.com (Rowan Collins)
On Thu, 25 Jul 2019 at 14:48, Nikita Popov ppv@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. 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]
  106298
July 25, 2019 15:17 nikita.ppv@gmail.com (Nikita Popov)
On Thu, Jul 25, 2019 at 4:41 PM Rowan Collins collins@gmail.com>
wrote:

> On Thu, 25 Jul 2019 at 14:48, Nikita Popov ppv@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
  106299
July 25, 2019 15:38 rowan.collins@gmail.com (Rowan Collins)
On Thu, 25 Jul 2019 at 16:18, Nikita Popov ppv@gmail.com> wrote:

>> 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]
  106304
July 28, 2019 02:47 smalyshev@gmail.com (Stanislav Malyshev)
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
  106309
July 28, 2019 13:01 ocramius@gmail.com (Marco Pivetta)
On Sun, Jul 28, 2019, 04:47 Stanislav Malyshev <smalyshev@gmail.com> wrote:

> 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.
  106311
July 28, 2019 19:06 smalyshev@gmail.com (Stanislav Malyshev)
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
  106312
July 28, 2019 19:12 ocramius@gmail.com (Marco Pivetta)
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/
  106314
July 28, 2019 19:23 smalyshev@gmail.com (Stanislav Malyshev)
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
  106319
July 29, 2019 08:39 claude.pache@gmail.com (Claude Pache)
> 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
  106320
July 29, 2019 11:08 ocramius@gmail.com (Marco Pivetta)
On Mon, Jul 29, 2019, 10:40 Claude Pache 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. >
Yes: usually replaced by `[]` or wrappers of those functions that de-reference the variables, so that no references are used.
>
  106327
July 29, 2019 21:10 smalyshev@gmail.com (Stanislav Malyshev)
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
  106322
July 29, 2019 14:40 nikita.ppv@gmail.com (Nikita Popov)
On Mon, Jul 29, 2019 at 10:40 AM Claude Pache 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
  106323
July 29, 2019 15:34 rowan.collins@gmail.com (Rowan Collins)
On Mon, 29 Jul 2019 at 15:41, Nikita Popov ppv@gmail.com> wrote:

> This proposal (at least combined with a declare that enforces use of > call-site annotations) addresses that concern. out/inout parameters do not > address this concern, because they are an mechanism that would be used *in > addition* to normal by-ref passing, and as such not address any problems it > has. > > The only way I see in which out/inout would actually address the concern > of this proposal is if out/inout were used instead of & at the call-site, > but the parameter were still a normal reference. I don't think that's a > good idea because it breaks symmetry between arguments and parameters, and > also squanders any future potential to use out/inout as a way to reduce > reference-use in this context. > > Does that make sense, Rowan? To put is more compactly, what I want is an > eventual state where given $fn($a) I have a guarantee that $a is not going > to be magically modified, without having to perform any global reasoning > about what $fn may refer to. If an alternative proposal does not result in > this eventual state, then it is not an alternative to this proposal (but > possibly still a valuable addition in itself). >
It does, yes. I guess what I had in mind was that *in the long-term*, out/inout parameters would replace & parameters, so rather than declare(require_reference_at_call_site=1) you would have declare(disable_reference_parameters=1). Whether or not it's a direct alternative to this proposal, I also worry that out/inout parameters are somewhat mutually exclusive with it: the more effort is spent on making reference parameters "better", the less appetite there will be for replacing them altogether. I agree the behaviour of type annotations would need deciding, but arguably that should have been true for by-reference parameters; it's somewhat bizarre that you can write "function foo(SomeClass &$x) { $x=42; }" The solution would probably be to reuse the "typed references" from the typed property implementation.
> Bob has brought up another interesting issue: This proposal currently does > not address the case of foo(...$a), where references into $a may be added > if foo() has by-reference parameters. The suggestion was to use foo(&...$a) > -- however in this case only to *allow* the use of references, not require > it (some args may be by-val while others may be by-ref). >
There's probably a bit of a rabbit-hole if the mission is "make references explicit". An array containing a reference can be passed by value, for instance, so $fn($a) might not technically modify $a, but still modify elements inside it. So it seems like we come back to "this is kind of useful information but may not actually offer a hard guarantee". Regards, -- Rowan Collins [IMSoP]
  106325
July 29, 2019 18:00 php-lists@koalephant.com (Stephen Reay)
> On 29 Jul 2019, at 22:34, Rowan Collins collins@gmail.com> wrote: > > 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
  106329
July 29, 2019 22:27 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Den 2019-07-29 kl. 20:00, skrev Stephen Reay:
>> On 29 Jul 2019, at 22:34, Rowan Collins collins@gmail.com> wrote: >> >> 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
  106331
July 29, 2019 22:47 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Den 2019-07-30 kl. 00:27, skrev Björn Larsson:

> Den 2019-07-29 kl. 20:00, skrev Stephen Reay: >>> On 29 Jul 2019, at 22:34, Rowan Collins collins@gmail.com> wrote: >>> >>> 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".
  106341
July 30, 2019 09:50 nikita.ppv@gmail.com (Nikita Popov)
On Mon, Jul 29, 2019 at 5:35 PM Rowan Collins collins@gmail.com>
wrote:

> On Mon, 29 Jul 2019 at 15:41, Nikita Popov ppv@gmail.com> wrote: > > > This proposal (at least combined with a declare that enforces use of > > call-site annotations) addresses that concern. out/inout parameters do > not > > address this concern, because they are an mechanism that would be used > *in > > addition* to normal by-ref passing, and as such not address any problems > it > > has. > > > > The only way I see in which out/inout would actually address the concern > > of this proposal is if out/inout were used instead of & at the call-site, > > but the parameter were still a normal reference. I don't think that's a > > good idea because it breaks symmetry between arguments and parameters, > and > > also squanders any future potential to use out/inout as a way to reduce > > reference-use in this context. > > > > Does that make sense, Rowan? To put is more compactly, what I want is an > > eventual state where given $fn($a) I have a guarantee that $a is not > going > > to be magically modified, without having to perform any global reasoning > > about what $fn may refer to. If an alternative proposal does not result > in > > this eventual state, then it is not an alternative to this proposal (but > > possibly still a valuable addition in itself). > > > > > It does, yes. I guess what I had in mind was that *in the long-term*, > out/inout parameters would replace & parameters, so rather than > declare(require_reference_at_call_site=1) you would have > declare(disable_reference_parameters=1). >
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
  106324
July 29, 2019 15:36 claude.pache@gmail.com (Claude Pache)
> Le 29 juil. 2019 à 16:40, Nikita Popov 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
  106326
July 29, 2019 21:05 smalyshev@gmail.com (Stanislav Malyshev)
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
  106328
July 29, 2019 22:02 nikita.ppv@gmail.com (Nikita Popov)
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
  106332
July 30, 2019 01:05 smalyshev@gmail.com (Stanislav Malyshev)
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
  106333
July 30, 2019 04:54 zeev@zend.com (Zeev Suraski)
> 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
  106347
July 30, 2019 15:10 morrison.levi@gmail.com (Levi Morrison)
On Mon, Jul 29, 2019, 10:55 PM Zeev Suraski <zeev@zend.com> wrote:

> > > > 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.
> -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
  106348
July 30, 2019 15:14 zeev@php.net (Zeev Suraski)
On Tue, Jul 30, 2019 at 6:10 PM Levi Morrison levi@gmail.com>
wrote:

> On Mon, Jul 29, 2019, 10:55 PM Zeev Suraski <zeev@zend.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
  106352
July 30, 2019 18:30 bobwei9@hotmail.com (Bob Weinand)
> Am 30.07.2019 um 17:14 schrieb Zeev Suraski <zeev@php.net>: > > On Tue, Jul 30, 2019 at 6:10 PM Levi Morrison levi@gmail.com> > wrote: > >> On Mon, Jul 29, 2019, 10:55 PM Zeev Suraski <zeev@zend.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
  106353
July 30, 2019 19:01 smalyshev@gmail.com (Stanislav Malyshev)
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
  106366
July 31, 2019 13:22 Danack@basereality.com (Dan Ackroyd)
On Tue, 30 Jul 2019 at 20:01, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> > 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
  106372
July 31, 2019 20:03 smalyshev@gmail.com (Stanislav Malyshev)
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
  106354
July 30, 2019 19:09 zeev@php.net (Zeev Suraski)
On Tue, Jul 30, 2019 at 9:30 PM Bob Weinand <bobwei9@hotmail.com> wrote:

> > 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
  106356
July 30, 2019 19:37 nikita.ppv@gmail.com (Nikita Popov)
On Tue, Jul 30, 2019 at 9:09 PM Zeev Suraski <zeev@php.net> wrote:

> On Tue, Jul 30, 2019 at 9:30 PM Bob Weinand <bobwei9@hotmail.com> wrote: > > > > 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
  106363
July 31, 2019 08:25 zeev@php.net (Zeev Suraski)
On Tue, Jul 30, 2019 at 10:37 PM Nikita Popov ppv@gmail.com> wrote:

> Zeev, > > Nikita,
Similarly to how I answered Bob, I want to prefix my message with an off-topic statement that I think is important, albeit obvious. I think you're a remarkably talented developer that is an invaluable asset to the PHP project. Your work on many fronts to improve the language has been tremendous, and much like pretty much everyone else - I recognize it. Again, even though I'm not telling you anything you don't already know, I want to remove any shred of doubt about whether or not I'm sharing this way of thinking. I do. And now, on-topic: 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.
Let's be fair and realistic here. You have a very strong following on internals@ - a position which is well-earned. In most situations when these folks don't have a strong opinion about a given matter, they would count on you to show the way and follow. When you make a statement that you're going to ignore someone - you are very much suppressing their voice; Beyond taking their ability to reason with the most relevant person, and get their opinion on the various issues raised - you're also signaling to your followers to do the same, whether you intend to or not. That said, I want to be clear - any RFC author is expected to explain and defend their RFC, responding to both feedback and criticism - even if they don't have the strong following you have. That following only makes it all the more clear and necessary. 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. >
There's a reason we call these things we do on internals "Discussion Periods". They're not meant to be similar to Closing Statements from the Prosecution and the Defense, trying to convince the jury without interacting with each other. In reality, much of the value of the RFC process comes from the discussion period - and discussion means back and forth. It helps both refine the RFC, weed out bad proposals, and perhaps most importantly - give people more of a 3D view of the RFC - become acquainted with the practical pros and cons of the RFC, some of its corner cases or unforseen impacts - which are often not as easy to understand from reading the formal RFC text itself. Refusing to take part in the discussion when provided with valid feedback hampers the RFC process. 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.
That makes perfect sense, but it also does not change the fact that you are absolutely *expected* to engage in the discussion regardless. It's comes with the territory. I'm sorry that everything has to be formalized today - had we seen that coming - we'd spell out that the discussion periods aren't meaningless countdown timers that the RFC author(s) can simply wait out, but rather, that they need to engage and respond to any meaningful feedback, and certainly not signal out certain folks by nature of who they are instead of the merit of their specific feedback. We thought that (as well as many other things) was obvious. I am not saying that one needs to respond to every last email message on the subject. There are situations where the discussion reaches a point where there's nothing new to say - on both sides of a certain divide (which is, incidentally, a pretty bad situation to be in to begin with, but that's another topic). But that's not what you're saying - you're saying you're going to stop responding to a person (perhaps more than one) - regardless of the content of feedback they provide. 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. >
While registering one's disapproval without explanation is definitely insufficient, I think we can agree that this wasn't the case here. Even without reading Stas's messages in detail - their length alone suggests that they provide reasoning for why he's disappoving of the idea, and not just crypitically saying that he disapproves. It becomes even clearer when you do read them in detail. But the other part if your sentence - that one must "suggest possible avenues for improvement or alternative approaches" is really not quite true. That wrongly assumes that an idea that's proposed in an RFC, any RFC - is a good one and should pass - and the goal of the discussion period is to simply hash out issues and make it better. That is clearly not the case. Everything about the RFC process as it was created - both in terms of the discussions before it, and the text itself - makes it clear that there's bias for status quo, and that the burden of proof is on the person that's proposing to change it. That's why we have 2/3 majority requirement (as insufficient as I think it may be). That's why we have a 6 month cool-off period after a proposal fails to pass. That's why the RFC template instructs people to think very carefully whether it's really sensible and necessary to have their feature/change introduced to a language used by so many millions of people. Nothing in the RFC process implies that everyone should help refine the RFC and make it better, if they think that the premise itself is a bad one. It's absolutely valid for someone to think a certain idea proposed is bad, and can't be improved. It's absolutely valid for someone to find holes in a proposal, and not have any ideas on how to fix them - these ideas may sometimes come from someone else. It's absolutely not a requirement for someone to come up with solutions for the problems they find in a proposal. Of course - if they do, that's great - but finding the edge cases, potential problems and possible negative effects - is extremely valuable on its own. Sometimes, the dynamics of the discussion between the feedback provider, RFC author and other participants will help find better solutions. In others, it may simply make people better understand the shortcomings (and advantages) of the RFC, and help them make up their mind about it. 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. >
It's hard for me to argue when someone is saying that if they do what's needed, it will have a negative influence on their mental well-being, as I'm so much familiar with it first hand. But the choice is yours, exactly like it's anyone's (including Stas's, who I'm sure would do much better from a mental well-being point of view if he didn't feel obligated to respond to ideas he believes are negative to the language he's so vested in, regardless of whether he's right or wrong; or me, for that matter, when I definitely took a negative hit on my mental well being a few weeks ago having to work hard to prevent a certain useful feature from being removed for no reason - a discussion I had no part in starting and was in a way forced on me). If you propose an RFC - you need to have the mental strength to follow through with it, and that includes responding to criticism, including criticism which from your point of view isn't constructive or insightful. If you can't, you have other choices - to not propose it, to have someone else author and lead that RFC, to propose fewer RFCs so that the level of mental strain are reduced, to focus on other less contentious areas, etc. For me, the negative influcence on my mental well-being was a key (if not exclusive) factor in the fact I never ended proposing the revamp of the Voting/RFC rules - and quite a lot of other proposals/RFCs over the years. I knew that if I did - I'd have to engage in unpleasant and often likely uncivilized discussions, including with some very uncivilized people who still believe they have the civilized higher ground (to clear any doubts, that's absolutely not you). It a part of the rules of the game. You can choose to play it, have someone else play it, or stay out. But one cannot play it while creating a sandboxed environment that shields them from feedback they don't like or people whose opinions they typically disagree with. It doesn't work that way. With all that said, it appears we would all do better if we came up with a way that the two 'camps' on internals, which hold opposing views on many topics regarding the direction of the language, could find a way where most or at least some (and hopefully many) of these discussions are avoided in the first place - but without blocking progress. None of us likes the mental toll associated with the current situation, and I think the results are often not very pleasing to either side. I'll be trying to work something out, who knows, it might just work. Zeev
  106357
July 30, 2019 19:45 Danack@basereality.com (Dan Ackroyd)
On Tue, 30 Jul 2019 at 20:09, Zeev Suraski <zeev@php.net> wrote:
> > 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
  106364
July 31, 2019 08:50 zeev@php.net (Zeev Suraski)
I believe I addressed most of what you wrote in my reply to Nikita, except
for this:

On Tue, Jul 30, 2019 at 10:45 PM Dan Ackroyd <Danack@basereality.com> wrote:

> On Tue, 30 Jul 2019 at 20:09, Zeev Suraski <zeev@php.net> wrote:
> If they do - it's absolutely their responsibility > > to defend their proposal > > Zeev, this isn't a rule that has been agreed. >
Dan, We also didn't agree anywhere that the discussions have to be in English, or that people aren't supposed to use curse words. The RFC RFC did not attempt to be a comprehensive detailed rulebook for every little detail or every scenario that may or may not happen. It took into account that what we already had on internals would continue to happen. That said - I have to admit that even if I had to do a rewrite - until recently - I would have never imagined we need to spell out that on-point feedback should be responded to, and that RFC authors cannot effectively 'boycott' people whose on-point feedback they don't like. Not everything has to be spelled out.
> But making vague threats to try to influence other contributors is > completely inappropriate behaviour.
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. Zeev
> >
  106367
July 31, 2019 13:31 Danack@basereality.com (Dan Ackroyd)
On Wed, 31 Jul 2019 at 09:50, Zeev Suraski <zeev@php.net> wrote:
> > 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
  106368
July 31, 2019 13:54 zeev@php.net (Zeev Suraski)
On Wed, Jul 31, 2019 at 4:31 PM Dan Ackroyd <Danack@basereality.com> wrote:

> On Wed, 31 Jul 2019 at 09:50, Zeev Suraski <zeev@php.net> wrote: > > > > 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."
  106369
July 31, 2019 14:09 guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")
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?

On Wed, Jul 31, 2019 at 9:54 AM Zeev Suraski <zeev@php.net> wrote:
> > On Wed, Jul 31, 2019 at 4:31 PM Dan Ackroyd <Danack@basereality.com> wrote: > > > On Wed, 31 Jul 2019 at 09:50, Zeev Suraski <zeev@php.net> wrote: > > > > > > 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
  106370
July 31, 2019 14:16 zeev@php.net (Zeev Suraski)
On Wed, Jul 31, 2019 at 5:09 PM guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:

> 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. >
Exactly. If making people stick to the rules we've been following for ages is considered 'pain, damage, or hostile action', and reaffirming the rules is considered 'retribution' in case they aren't clear, then yes, it was a threat. But on this planet, it wasn't. Zeev
  106371
July 31, 2019 19:59 smalyshev@gmail.com (Stanislav Malyshev)
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
  106305
July 28, 2019 02:56 smalyshev@gmail.com (Stanislav Malyshev)
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
  106330
July 29, 2019 22:44 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Den 2019-07-25 kl. 14:32, skrev Nikita Popov:
> On Wed, Dec 6, 2017 at 8:49 PM Nikita Popov ppv@gmail.com> wrote: > >> 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
  106334
July 30, 2019 06:14 nicolas.grekas@gmail.com (Nicolas Grekas)
Le mer. 6 déc. 2017 à 20:50, Nikita Popov 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
  106337
July 30, 2019 08:34 rowan.collins@gmail.com (Rowan Collins)
On Tue, 30 Jul 2019 at 07:14, Nicolas Grekas 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]
  106339
July 30, 2019 09:00 nicolas.grekas+php@gmail.com (Nicolas Grekas)
Le mar. 30 juil. 2019 à 10:34, Rowan Collins collins@gmail.com> a
écrit :

> On Tue, 30 Jul 2019 at 07:14, Nicolas Grekas 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.
  106340
July 30, 2019 09:30 rowan.collins@gmail.com (Rowan Collins)
On Tue, 30 Jul 2019 at 10:00, Nicolas Grekas 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]
  106343
July 30, 2019 10:28 nikita.ppv@gmail.com (Nikita Popov)
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 collins@gmail.com> a > écrit : > > > On Tue, 30 Jul 2019 at 07:14, Nicolas Grekas 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
  106344
July 30, 2019 12:34 rowan.collins@gmail.com (Rowan Collins)
On Tue, 30 Jul 2019 at 11:28, Nikita Popov ppv@gmail.com> wrote:

> 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]