On Friday, December 8, 2017 12:42 PM, "Stephen Rea" < php-li...@koalephant.com> wrote: >> On 8 Dec 2017, at 08:54, "li...@rhsoft.net" <li...@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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
