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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
