Re: [RFC][PRE-VOTE] In Operator

2015-03-15 3:34 GMT+01:00 Stanislav Malyshev <smalyshev@gmail.com>: > Hi! > >> I'd like to announce that I'll open the vote for the in operator later that day. >> You can find the RFC here: https://wiki.php.net/rfc/in_operator >> ºÊNË@¤kB*«§ > > I think this operator is unnecessary - we already have perfectly good > function that does the same. If they were "perfectly good", ... > Also, since it checks the values and not > the keys, it would be useless for the same use case one would most > frequently use "in" in Python and such - for checking if something is in > a set of values. Since efficient implementation of the set in PHP would > have the value being sought as key, "in" would be useless, unless much > slower iterative implementation is chosen. We already have a language construct here that's not a function call: isset. > Also, because it includes different (and inconsistent) implementation > for strings, if you have ("foo" in $bar === true) , you don't know if > $bar is an array that includes string "foo" or a string that has "foo" > as a substring. I don't think it's good that operator would mix these > two cases. It's different for strings, yes, but where's the inconsistency? A common user case would probably be checking user input against a set of values. As others already mentioned in the discussion there have been security issues using non-strict in_array in the past. > -- > Stas Malyshev > smalyshev@gmail.com Regards, Niklas