Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83366
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 50470 invoked from network); 21 Feb 2015 00:45:17 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 21 Feb 2015 00:45:17 -0000
Authentication-Results: pb1.pair.com header.from=me@kelunik.com; sender-id=unknown
Authentication-Results: pb1.pair.com smtp.mail=me@kelunik.com; spf=permerror; 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:52608] helo=mo4-p00-ob.smtp.rzone.de)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id C2/C0-45394-A15D7E45 for <internals@lists.php.net>; Fri, 20 Feb 2015 19:45:16 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1424479511; l=9960;
	s=domk; d=kelunik.com;
	h=Content-Type:Cc:To:From:Subject:Date:References:In-Reply-To:
	MIME-Version;
	bh=+hrFt9vJPzv/UHrJWiR6QPJr6NDNTFaUKjTALjfbriU=;
	b=Arj3ORubwfGdxlzlk5DjSZPFgl2Lvtnl5/8iYeGhwI9T9wzjxoOFTwDuuouvNSpOX9V
	EtEEN5cIsx18u8+o8Dk2tudxELCSCf+sLc+FUaiTq0HuAIxm8Z7AriJHy0qifEByd+xD5
	APdtuyWFKQg4zlD/S74gORrSKc9i/09KYfg=
X-RZG-AUTH: :IWkkfkWkbvHsXQGmRYmUo9mls2vWuiu+7SLDup6E67mzuoNNBqD/tX0=
X-RZG-CLASS-ID: mo00
Received: from mail-wi0-f175.google.com ([209.85.212.175])
	by smtp.strato.de (RZmta 37.3 AUTH)
	with ESMTPSA id R063d9r1L0jBfkv
	(using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	for <internals@lists.php.net>;
	Sat, 21 Feb 2015 01:45:11 +0100 (CET)
Received: by mail-wi0-f175.google.com with SMTP id r20so6390228wiv.2
        for <internals@lists.php.net>; Fri, 20 Feb 2015 16:45:11 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.175.202 with SMTP id cc10mr520809wjc.27.1424479511615;
 Fri, 20 Feb 2015 16:45:11 -0800 (PST)
Received: by 10.27.77.131 with HTTP; Fri, 20 Feb 2015 16:45:11 -0800 (PST)
In-Reply-To: <CALwr1GmOnsB8O2yu+ri92u5XvF9a0UxdU2s7GVE03BQnpQPESQ@mail.gmail.com>
References: <CANUQDCiPP9=_=ZDX7prvCNdXvxZRs3Awq-FaLDDE5K-U3hXZRQ@mail.gmail.com>
	<54E7C558.7030900@garfieldtech.com>
	<CALwr1GmOnsB8O2yu+ri92u5XvF9a0UxdU2s7GVE03BQnpQPESQ@mail.gmail.com>
Date: Sat, 21 Feb 2015 01:45:11 +0100
Message-ID: <CANUQDCiGExFRvbPYit7KWv8EWpFv0XuYmz+tU6=rZUVr3p5dog@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: multipart/alternative; boundary=089e013d0f4847a350050f8e7b62
Subject: Re: [PHP-DEV] [RFC][Discussion] In Operator
From: me@kelunik.com (Niklas Keller)

--089e013d0f4847a350050f8e7b62
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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
would 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 tha=
t
> 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

--089e013d0f4847a350050f8e7b62--