Req #72866 [Com]: change default of $strict parameter of in_array()

From: Date: Wed, 17 Aug 2016 19:06:51 +0000
Subject: Req #72866 [Com]: change default of $strict parameter of in_array()
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-203360@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=72866&edit=1

 ID:                 72866
 Comment by:         ryosuke_i_628 at yahoo dot co dot jp
 Reported by:        imbibinebe at gmail dot com
 Summary:            change default of $strict parameter of in_array()
 Status:             Re-Opened
 Type:               Feature/Change Request
 Package:            *General Issues
 Operating System:   debian
 PHP Version:        5.6Git-2016-08-17 (Git)
 Block user comment: N
 Private report:     N

 New Comment:

>> And at least, the final result resulting of my test is:

>> // 'string' == 0 -> bool(true)

>> should that be allright ? :)

Ooooops!!
String starts with non-numeric char is equivalent to zero.
My examples were completely wrong, sorry...

Needless to say this feature is very very confusing lol


Previous Comments:
------------------------------------------------------------------------
[2016-08-17 16:05:58] cmb@php.net

> I wished it as a feature request.

Actually, you had submitted it as feature request, but it sounded
more like a bug report to me.

> I think that having "bool $strict = FALSE" by default is very
> confusing (should be TRUE).

Okay, that might be possible without RFC, but at least some
discussion on internals@lists.php.net seems appropriate. Feel free
to write to the list.

------------------------------------------------------------------------
[2016-08-17 15:50:58] imbibinebe at gmail dot com

Sorry, Submitting this as a bug was my mistake. I wished it as a feature request.
I think that having "bool $strict = FALSE" by default is very confusing (should be TRUE).
At least the 2nd rule you gave me here is complex enough for not being the default behaviour in the
case of in_array function, I guess ...
Thank you all for your answers anyway.

------------------------------------------------------------------------
[2016-08-17 15:34:17] cmb@php.net

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to
report
a bug at http://bugs.php.net/how-to-report.php

The manual states[1]:

| If you compare a number with a string or the comparison involves
| numerical strings, then each string is converted to a number and
| the comparison performed numerically.

And[2]:

| The value is given by the initial portion of the string. If the
| string starts with valid numeric data, this will be the value
| used. Otherwise, the value will be 0 (zero).

[1] <http://php.net/manual/en/language.operators.comparison.php>
[2] <http://php.net/manual/en/language.types.string.php#language.types.string.conversion>

------------------------------------------------------------------------
[2016-08-17 14:32:21] imbibinebe at gmail dot com

And at least, the final result resulting of my test is:

// 'string' == 0 -> bool(true)

should that be allright ? :)

------------------------------------------------------------------------
[2016-08-17 14:27:24] ryosuke_i_628 at yahoo dot co dot jp

Sorry, I was missing your important sentence:

> 'Expected result' should be obtained without using the third parameter of in_array

BTW, I think this behavior seems to be a little odd, too...

Probably you know the related issue; array_unique() was broken at PHP 5.2.9 due to use SORT_REGULAR
by default, which feature is reverted at PHP 5.2.10 to use SORT_STRING.

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=72866


--
Edit this bug report at https://bugs.php.net/bug.php?id=72866&edit=1


Thread (9 messages)

« previous php.bugs (#203360) next »