2015-03-15 3:34 GMT+01:00 Stanislav Malyshev <[email protected]>:
> 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
>
> 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
> [email protected]
Regards, Niklas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
