On 5 December 2014 01:07:03 GMT, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: >Hi all, > >On Thu, Dec 4, 2014 at 5:28 PM, Yasuo Ohgaki <yohg...@ohgaki.net> >wrote: > >> I think we can get rid of this error now when literal is returned. >> The reason we have E_STRICT error is that legacy PHP didn't >> support this, I suppose. >> >> http://3v4l.org/8fISj >> >> Is it possible to allow literal as referenced parameter for PHP7? >> It's better to remove needless restrictions where it is possible. >> HHVM seems already support this. >> >> http://3v4l.org/t79rF >> >> Any comments? >> > >It may be better to focus on return value from functions/methods. > >There are cases that return values are better to be treated as usual >variables. For example, > ><?php >function f1(&$v) {} >function f2() {$a = array(1,2,3); return $a; } > >f1(f2()); >?> > >http://3v4l.org/2prWX > >E_STRICT error here is too much. IMHO. >I think this kind of code should be allowed without errors rather than >forcing users to save return value to variable. e.g. > >$v = f2(); >f1($v);
The author of function f1() presumably designed it to apply some change to $v, rather than executing only for its side effects and return value. If the caller wants to ignore this design, they can, but they are not using the function as it was designed. If they pass a function return straight into it, they have no way of capturing the change to $v which the author intended them to see. E_STRICT seems like the perfect output for that: "what you're doing will work, but it's probably not the best idea, and there's an easy tweak you might want to consider". You might want some way of saying "no, I really meant to do that" (more elegantly than the @ operator), but E_STRICT is full of hints like this that border on coding style, so if you don't like that, just mask it out of error_reporting. That's my 2 pence, anyway. -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
