Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84810
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.218 cause and error)
MIME-Version: 1.0
In-Reply-To: <5504EF9D.1000707@gmail.com>
References: <CANUQDCjK7F1H5PZeV4XXvbDOsmyYtG4P1fPH3QnKBuY9EM-JdA@mail.gmail.com>
	<5504EF9D.1000707@gmail.com>
Date: Sun, 15 Mar 2015 10:18:14 +0100
Message-ID: <CANUQDCiAyprWB7A_aZ1f1SztaKP88GA=rnEE2eb8RBM2FOxO+g@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC][PRE-VOTE] In Operator
From: me@kelunik.com (Niklas Keller)

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
>
> 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