# [RFC][Discussion] In Operator

- Thread: https://externals.io/message/83293
- Original archive: https://news-web.php.net/php.internals/83293
- Started by Niklas Keller on 2015-02-20T12:54:26+00:00
- Messages: 11
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #83293 — Niklas Keller — 2015-02-20T12:54:26+00:00

URL: https://externals.io/message/83293#83293

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

Question: The timline says "Line up any remaining RFCs that target PHP
7.0.", does that mean RFCs have to
start voting on Mar 15 or should the vote end there?

It would really make sense to vote on this RFC after there has been a
vote on https://wiki.php.net/rfc/context_sensitive_lexer.

Regards, Niklas

---

## #83314 — johannes@schlueters.de — 2015-02-20T15:55:09+00:00

URL: https://externals.io/message/83293#83314 · In reply to: #83293

> Hi internals,
> 
> "In Operator" is now in discussion phase.
> 
> > […]
> 
> 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

---

## #83325 — padraic.brady@gmail.com — 2015-02-20T16:56:12+00:00

URL: https://externals.io/message/83293#83325 · In reply to: #83314

> 
> > […]
>
> | 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.

I would be in favour of strict comparison. Being consistent with
 `in_array()` sounds great, but the loose comparison makes it difficult
to use in certain use cases. A common usage would be a contains/in
validator, for example, where loose comparisons can pass unwanted
values depending on how it's written. I'm not fumbling in the dark, it
has created a security issue in at least two frameworks.

Since it's a new operator in isolation, tightening such rules would be welcome.

Paddy

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com

---

## #83327 — Dan Ackroyd — 2015-02-20T17:16:20+00:00

URL: https://externals.io/message/83293#83327 · In reply to: #83293

> Hi internals,
>
> It would really make sense to vote on this RFC after there has been a
> vote on https://wiki.php.net/rfc/context_sensitive_lexer.

That is an understatement:
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Query/Expr.php#L443

I don't think changing the language in a way that breaks Doctrine
would be feasible.

cheers
Dan

---

## #83331 — Benoit Schildknecht — 2015-02-20T17:40:29+00:00

URL: https://externals.io/message/83293#83331 · In reply to: #83293

Le Fri, 20 Feb 2015 13:54:26 +0100, Niklas Keller <me@kelunik.com> a écrit:

> Hi internals,
>
> "In Operator" is now in discussion phase.
>
> It would really make sense to vote on this RFC after there has been a
> vote on https://wiki.php.net/rfc/context_sensitive_lexer.
>
> Regards, Niklas

I agree. Context Sensitive Lexer have to be voted first.

---

## #83339 — Markus Fischer — 2015-02-20T18:48:17+00:00

URL: https://externals.io/message/83293#83339 · In reply to: #83327

> 
> > […]
> 
> That is an understatement:
> https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Query/Expr.php#L443
> 
> I don't think changing the language in a way that breaks Doctrine
> would be feasible.

I second this. I didn't immediately reply when I read this restriction
regarding methods but it should have been obvious.

IMHO this is an absolute no-go; and the contex_sensitive_lexer sounds
reasonable but has it's own problematic areas.

- Markus

---

## #83353 — Niklas Keller — 2015-02-20T20:17:06+00:00

URL: https://externals.io/message/83293#83353 · In reply to: #83339

2015-02-20 19:48 GMT+01:00 Markus Fischer <markus@fischer.name>:
> 
> > […]
>
> I second this. I didn't immediately reply when I read this restriction
> regarding methods but it should have been obvious.
>
> IMHO this is an absolute no-go; and the contex_sensitive_lexer sounds
> reasonable but has it's own problematic areas.
>
> - Markus
>
> --
> 
> 
>

It would clearly break Doctrine in its current state if we don't get
in that context sensitive
parser, but I want to point out, that it would still be fixable by
using a magic method for that,
like it's pointed out here:
https://twitter.com/danielgsims/status/568823804849496064

Of course that would be rather hacky.

Regards, Niklas

---

## #83363 — Larry Garfield — 2015-02-20T23:38:00+00:00

URL: https://externals.io/message/83293#83363 · In reply to: #83293

> Hi internals,
>
> "In Operator" is now in discussion phase.
>
> > […]
> https://wiki.php.net/rfc/in_operator
>
> Question: The timline says "Line up any remaining RFCs that target PHP
> 7.0.", does that mean RFCs have to
> start voting on Mar 15 or should the vote end there?
>
> It would really make sense to vote on this RFC after there has been a
> vote on https://wiki.php.net/rfc/context_sensitive_lexer.
>
> Regards, Niklas

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.

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.

--Larry Garfield

---

## #83364 — padraic.brady@gmail.com — 2015-02-21T00:07:39+00:00

URL: https://externals.io/message/83293#83364 · In reply to: #83363

> 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 === 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ádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com

---

## #83366 — Niklas Keller — 2015-02-21T00:45:11+00:00

URL: https://externals.io/message/83293#83366 · In reply to: #83364

2015-02-21 1:07 GMT+01:00 Pádraic Brady <padraic.brady@gmail.com>:
> On 20 February 2015 at 23:38, Larry Garfield <larry@garfieldtech.com>
wrote:
> > […]
be a
> > […]
would be
> > […]
that
> > […]
>
> 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 === as our toe in the water.
>
> > […]
as
> > […]
have
> > […]
>
> 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ádraic Brady
>
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
>
> --
> 
> 
>

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 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

---

## #83920 — Niklas Keller — 2015-02-26T19:49:35+00:00

URL: https://externals.io/message/83293#83920 · In reply to: #83366

2015-02-21 1:45 GMT+01:00 Niklas Keller <me@kelunik.com>:
> 2015-02-21 1:07 GMT+01:00 Pádraic Brady <padraic.brady@gmail.com>:
> > […]
>
> > […]
>
>
> You could easily cast the left operand to a string instead.
>
> > […]
>
>
> 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.
>
> > […]
>
> Not really. It could be named `contains`, but that would create the same
> problems.
>
> > […]
>
>
> 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