On Wed, Jan 8, 2020 at 1:23 PM Björn Larsson <bjorn.x.lars...@telia.com> wrote:
> Den 2020-01-07 kl. 21:57, skrev George Peter Banyard: > > Greetings internals, > > > > I would like your input on adding TypeError and ValueError exceptions > > to the count() function in respect to the Consistent type errors for > > internal functions RFC [1], the initial PR [2] was denied as null was > > not accepted as a value when it seems to be prevalent to use count() > > as a substitute for isset() (this is currently done in the test runner > > for php-src), although a "type error" warning was already emitted with > > null. > > > > So I've made an adjustment by still accepting null but deprecating it's > > usage. An other option is to allow null as a value that always return 0. > > > > I've also added a ValueError exception on invalid modes. > > The new pull request is located at > https://github.com/php/php-src/pull/4940 > > > > Any comments would be appreciated. > > > > Best regards and happy new year. > > > > George Peter Banyard > > > > [1] https://wiki.php.net/rfc/consistent_type_errors > > [2] https://github.com/php/php-src/pull/4572 > > Hi, > > My take on this is that when converting a legacy code base from > PHP 5.2 to PHP 7.4, the RFC Counting of non-countable objects > generated quite a lot of hassle. Count was used for checking > return of DB values. Code piece could e.g. look like: > for($i=0; $i<count($blog_result); $i++){ > $blog_result[$i]->nrOfComments = > $blog->getNumberOfComments($blog_result[$i]->id); > } > > If I read this correctly, with warnings today as is, the code after > will continue, but with exception I presume execution will stop > (unless I catch it of course). > > I still have warnings to weed out from legacy code but also > from Smarty library. So I wonder what impact this change > will have? I mean, I can live with the warnings fixing code > bit by bit... > > r//Björn L In the cases you encountered, do you know what type count() was used on? Was it null? false? Or something else? Nikita
