Re: [RFC][Discussion] In Operator

From: Date: Fri, 20 Feb 2015 16:56:12 +0000
Subject: Re: [RFC][Discussion] In Operator
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-83325@lists.php.net to get a copy of this message
On 20 February 2015 at 15:55, Johannes Schlüter <johannes@schlueters.de> wrote: > On Fri, 2015-02-20 at 13:54 +0100, Niklas Keller wrote: >> Hi internals, >> >> "In Operator" is now in discussion phase. >> >> > This RFC adds a new in operator which simplifies contains checks for strings and >> > arrays. >> > Currently, we have to usein_array($needle, $haystack, true) or strpos($haystack, >> > $needle) !== false. >> > These functions have a inconsistent parameter order, so it's hard to remember >> > which is the right one >> > for each. The in operator makes these checks way more readable. Additionally, it also >> > works for Traversable. >> >> https://wiki.php.net/rfc/in_operator > > | It uses strict comparison (===) for array values / instances of > | Traversable > > This might be nice but is inconsistent with other parts of the language > like switch statements. I think inconsistency is worse than this > inconvenience. I would be in favour of strict comparison. Being consistent with in_array() sounds great, but the loose comparison makes it difficult to use in certain use cases. A common usage would be a contains/in validator, for example, where loose comparisons can pass unwanted values depending on how it's written. I'm not fumbling in the dark, it has created a security issue in at least two frameworks. Since it's a new operator in isolation, tightening such rules would be welcome. Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com

« previous php.internals (#83325) next »