Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83314
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
Message-ID: <1424447709.16516.2.camel@kuechenschabe>
To: Niklas Keller <me@kelunik.com>
Cc: PHP Internals <internals@lists.php.net>
Date: Fri, 20 Feb 2015 16:55:09 +0100
In-Reply-To: <CANUQDCiPP9=_=ZDX7prvCNdXvxZRs3Awq-FaLDDE5K-U3hXZRQ@mail.gmail.com>
References: 
	<CANUQDCiPP9=_=ZDX7prvCNdXvxZRs3Awq-FaLDDE5K-U3hXZRQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][Discussion] In Operator
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

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. 

johannes