Am 08.12.2017 um 05:41 schrieb Stephen Reay:
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
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
