Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83920
Return-Path: <me@kelunik.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 69835 invoked from network); 26 Feb 2015 19:49:41 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 26 Feb 2015 19:49:41 -0000
Authentication-Results: pb1.pair.com smtp.mail=me@kelunik.com; spf=permerror; sender-id=unknown
Authentication-Results: pb1.pair.com header.from=me@kelunik.com; sender-id=unknown
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.216 cause and error)
X-PHP-List-Original-Sender: me@kelunik.com
X-Host-Fingerprint: 81.169.146.216 mo4-p00-ob.smtp.rzone.de  
Received: from [81.169.146.216] ([81.169.146.216:50323] helo=mo4-p00-ob.smtp.rzone.de)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 4F/5D-32582-2D87FE45 for <internals@lists.php.net>; Thu, 26 Feb 2015 14:49:39 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1424980175; l=4216;
	s=domk; d=kelunik.com;
	h=Content-Transfer-Encoding:Content-Type:Cc:To:From:Subject:Date:
	References:In-Reply-To:MIME-Version;
	bh=KWOwFReipr8mfJLW51Z/99zrDlCD1Hw1wEg7we7UWn4=;
	b=pfS2eaP2uasr6tVhdK6mI5RIr3pNJqrCwPi5xrl7edPd3DWrV85yFzqceJskz63xaee
	Xu5TwxQ7A68ySwoxipeKw1xgQCXVx93X1gJU8aWHrCX+ED3wVNRRZPiOT/ykdfv3RWUgL
	qQlN4u9dVLjNawA5v+SiW0LQxbO/4Qi3pwA=
X-RZG-AUTH: :IWkkfkWkbvHsXQGmRYmUo9mls2vWuiu+7SLGvomb4bl9EfHtPnRQ9w==
X-RZG-CLASS-ID: mo00
Received: from mail-we0-f177.google.com ([74.125.82.177])
	by smtp.strato.de (RZmta 37.3 AUTH)
	with ESMTPSA id K04168r1QJnZ6gn
	(using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	for <internals@lists.php.net>;
	Thu, 26 Feb 2015 20:49:35 +0100 (CET)
Received: by wevk48 with SMTP id k48so14207480wev.3
        for <internals@lists.php.net>; Thu, 26 Feb 2015 11:49:35 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.175.202 with SMTP id cc10mr20198317wjc.27.1424980175243;
 Thu, 26 Feb 2015 11:49:35 -0800 (PST)
Received: by 10.27.77.131 with HTTP; Thu, 26 Feb 2015 11:49:35 -0800 (PST)
In-Reply-To: <CANUQDCiGExFRvbPYit7KWv8EWpFv0XuYmz+tU6=rZUVr3p5dog@mail.gmail.com>
References: <CANUQDCiPP9=_=ZDX7prvCNdXvxZRs3Awq-FaLDDE5K-U3hXZRQ@mail.gmail.com>
	<54E7C558.7030900@garfieldtech.com>
	<CALwr1GmOnsB8O2yu+ri92u5XvF9a0UxdU2s7GVE03BQnpQPESQ@mail.gmail.com>
	<CANUQDCiGExFRvbPYit7KWv8EWpFv0XuYmz+tU6=rZUVr3p5dog@mail.gmail.com>
Date: Thu, 26 Feb 2015 20:49:35 +0100
Message-ID: <CANUQDCiL1eA7qy86OmK7XddLh+s0xB4ViDeWDKbfP8GROB=o6w@mail.gmail.com>
To: =?UTF-8?Q?P=C3=A1draic_Brady?= <padraic.brady@gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC][Discussion] In Operator
From: me@kelunik.com (Niklas Keller)

2015-02-21 1:45 GMT+01:00 Niklas Keller <me@kelunik.com>:
> 2015-02-21 1:07 GMT+01:00 P=C3=A1draic Brady <padraic.brady@gmail.com>:
>> On 20 February 2015 at 23:38, Larry Garfield <larry@garfieldtech.com>
>> wrote:
>>> While I love the idea, strict type comparison for in would, in essence,
>>> be a
>>> toe-dip into the scalar strict typing world (see other thread) that wou=
ld
>>> be
>>> very confusing.  Consider:
>>>
>>> if (3 in $_GET['filters']) { ... }
>>>
>>> That would always be false, because $_GET is always strings.  To make
>>> that
>>> work I'd need to first cast all of the elements in that array to ints..=
.
>>> which I'm not actually sure how to do cleanly.
>>
>> You need casting anyway if comparing raw GET/POST directly to any
>> integer as a decision point on whether to use the raw value, i.e. it's
>> unvalidated otherwise and could have been "1234<script>[...]".
>>
>> Yes, I'm abusing your intentionally very simple example. There are
>> other cases away from user input where looser comparisons wouldn't
>> have the same potential issues with non-permanent type juggling. I
>> would be a huge fan of having it be strict since the above, while
>> clearly a simple example, has been problematic in the past for
>> validation routines and, as a security guy, I'm obsessed with that ;).
>> Also, on toe-dipping into strict typing, I think your opinion may be
>> slightly overweight towards that topic given recent RFC history - we
>> already have =3D=3D=3D as our toe in the water.
>>
>>> I'd much rather we tighten up the rules around implicit casts generally=
,
>>> as
>>> discussed elsewhere, and then allow those "loose but not as loose as we
>>> have
>>> now" rules here.
>>
>> I could work with that perhaps. RFCs of this type are in a bit of a
>> bind while we wait for scalar typehints/potential casting rules to be
>> finalized in some form. It also appears unlikely that "in" as the
>> operator name will pass muster if the context sensitive lexer RFC does
>> not pass, i.e. would break uses of in() as a method name.
>>
>> Niklas, any chance you have considered a Plan B for the operator
>> naming? Mostly curious if these is already some alternative outside of
>> the field of langs I'm familiar with that might be acceptable.
>>
>> Paddy
>>
>> --
>> P=C3=A1draic Brady
>>
>> http://blog.astrumfutura.com
>> http://www.survivethedeepend.com
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>> if (3 in $_GET['filters']) { ... }
>> That would always be false, because $_GET is always strings.  To make th=
at
>> work I'd need to first cast all of the elements in that array to ints...
>> which I'm not actually sure how to do cleanly.
>
>
> You could easily cast the left operand to a string instead.
>
>> I'd much rather we tighten up the rules around implicit casts generally,
>> as discussed elsewhere, and then allow those "loose but not as loose as =
we
>> have now" rules here.
>
>
> Maybe I'd be OK with that then, but not in the state we currently have. I
> think a change here would be too rushed and would therefore have to wait
> until PHP 8.
>
>> Niklas, any chance you have considered a Plan B for the operator
>> naming? Mostly curious if these is already some alternative outside of
>> the field of langs I'm familiar with that might be acceptable.
>
> Not really. It could be named `contains`, but that would create the same
> problems.
>
>> It also appears unlikely that "in" as the
>> operator name will pass muster if the context sensitive lexer RFC does
>> not pass, i.e. would break uses of in() as a method name.
>
>
> You're totally right. It's already the second RFC on that topic
> (https://wiki.php.net/rfc/keywords_as_identifiers is the other one I know=
).
> If context sensitive lexer doesn't parse, "in" may have to wait until PHP=
 8,
> which may have another RFC here.
>
> Regards, Niklas

I've updated the RFC to v0.4. I removed support for using arrays to
check for multiple values.
Additionally, it's implemented now if somebody wants to test it.

Regards, Niklas