# in Operator

- Thread: https://externals.io/message/80850
- Original archive: https://news-web.php.net/php.internals/80850
- Started by Niklas Keller on 2015-01-19T00:42:57+00:00
- Messages: 17
- 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

---

## #80850 — Niklas Keller — 2015-01-19T00:42:57+00:00

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

Hello,

I'd like to propose a new feature to PHP: The in Operator
Bob mentioned a few weeks ago he wants such an operator in PHP and today I
stumbled over
http://nikic.github.io/2012/07/27/How-to-add-new-syntactic-features-to-PHP.html
again,
which uses the in operator as a sample.

Use cases:

$obj = new StdClass;
$obj->prop = "value";
$languages = ["PHP", "C", "Java"];
var_dump("PHP" in $languages); // true
var_dump("Python" in $languages); // false
var_dump(0 in $languages); // false
var_dump("0x0" in ["0e3"]); // false
var_dump("prop" in $obj); // true
var_dump("foo" in $obj); // false
var_dump("Hello" in "Hello World!"); // true

For strings, it would replace `strpos("Hello World!", "Hello") !== false)`,
for arrays it would replace `in_array($needle, $haystack, true)`
and for objects it would be a replacement of property_exists($class,
$property)`.

This change would mainly be syntax sugar, but I think it's worth because:
 * `"0x0" in ["0e3"]` would return false while `in_array("0x0", ["0e3"])`
returns true, that's probably an edge case, but there may be a lot of
people that don't use the `$strict` parameter, see http://3v4l.org/0K7E5
 * It would solve the issue that it's hard to remember the order of the
arguments for in_array and strpos, just had to look it up again.

Bob would volunteer to implement that feature.

Best Regards
Niklas Keller

---

## #80852 — Mike Willbanks — 2015-01-20T03:30:03+00:00

URL: https://externals.io/message/80850#80852 · In reply to: #80850

Hello Niklas,



> Hello,
>
> I'd like to propose a new feature to PHP: The in Operator
> Bob mentioned a few weeks ago he wants such an operator in PHP and today I
> stumbled over
>
> http://nikic.github.io/2012/07/27/How-to-add-new-syntactic-features-to-PHP.html
> again,
> which uses the in operator as a sample.
>

I am very familiar with the in operator.  However,  the implementation
would be incomplete without handling loops via the in operator.  Many
people when seeing an in operator also think of JavaScript.  In that case
the in operator iterates over properties.  As such in PHP we should be able
to iterate over associative arrays should the syntax be added.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...in


> Use cases:
>
> $obj = new StdClass;
> $obj->prop = "value";
> $languages = ["PHP", "C", "Java"];
> var_dump("PHP" in $languages); // true
> var_dump("Python" in $languages); // false
> var_dump(0 in $languages); // false
> var_dump("0x0" in ["0e3"]); // false
> var_dump("prop" in $obj); // true
> var_dump("foo" in $obj); // false
> var_dump("Hello" in "Hello World!"); // true
>
> For strings, it would replace `strpos("Hello World!", "Hello") !== false)`,
> for arrays it would replace `in_array($needle, $haystack, true)`
> and for objects it would be a replacement of property_exists($class,
> $property)`.
>
> This change would mainly be syntax sugar, but I think it's worth because:
>  * `"0x0" in ["0e3"]` would return false while `in_array("0x0", ["0e3"])`
> returns true, that's probably an edge case, but there may be a lot of
> people that don't use the `$strict` parameter, see http://3v4l.org/0K7E5
>  * It would solve the issue that it's hard to remember the order of the
> arguments for in_array and strpos, just had to look it up again.
>

I do think that it would be nice for a few different reasons but the in
operator as such can also cause a bit of confusion and misdirection
depending on how it is implemented.  In the use cases above you do mention
some inconsistencies with PHP functions that already exist.  Additionally
you did mention objects, in what scope would it properly leverage?  My
assumption would be visible properties from the context which you are in.

Regards,

Mike

---

## #80854 — Andrea Faulds — 2015-01-20T05:15:55+00:00

URL: https://externals.io/message/80850#80854 · In reply to: #80852

Hi Mike,

> 
> 
> I am very familiar with the in operator.  However,  the implementation
> would be incomplete without handling loops via the in operator.  Many
> people when seeing an in operator also think of JavaScript.  In that case
> the in operator iterates over properties.  As such in PHP we should be able
> to iterate over associative arrays should the syntax be added.
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...in

Why? We already have foreach/as which does exactly that, and unlike JS which added for/of, there’s nothing wrong with PHP’s foreach so we don’t need support for a new symbol.

--
Andrea Faulds
http://ajf.me/

---

## #80857 — Pierre Joye — 2015-01-20T05:35:59+00:00

URL: https://externals.io/message/80850#80857 · In reply to: #80854

> Hi Mike,
>
> > […]
>
> Why? We already have foreach/as which does exactly that, and unlike JS which added for/of, there’s nothing wrong with PHP’s foreach so we don’t need support for a new symbol.

Indeed, exactly same feature.

Otherwise, well done again Andrea, love it ::)

-- 
Pierre

@pierrejoye | http://www.libgd.org

---

## #80867 — Niklas Keller — 2015-01-20T09:27:23+00:00

URL: https://externals.io/message/80850#80867 · In reply to: #80857

2015-01-20 6:35 GMT+01:00 Pierre Joye <pierre.php@gmail.com>:
> 
> > […]
>
> Indeed, exactly same feature.
>
> Otherwise, well done again Andrea, love it ::)
>
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org

Hi Mike and Andrea,

> In that case the in operator iterates over properties.  As such in PHP we should be able to iterate over associative arrays should the syntax be added.

The reason why I didn't include this the reason Andrea mentioned: We
already have `foreach`.

> My assumption would be visible properties from the context which you are in.

Yes, this is what I'd suggest.

Regards,
Nick

---

## #80872 — Mike Willbanks — 2015-01-20T13:41:45+00:00

URL: https://externals.io/message/80850#80872 · In reply to: #80857

Hello Pierre, Andrea and Niklas,



> 
> > […]
> case
> > […]
> able
> > […]
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...in
> > […]
> which added for/of, there’s nothing wrong with PHP’s foreach so we don’t
> need support for a new symbol.
>
> Indeed, exactly same feature.


It certainly is the same feature from the foreach perspective.  I'm not
against leaving it out, however, it would be much like the in operator thus
providing some additional syntax sugar.  Many people that often program in
JavaScript are used to having:
array.forEach(function()),  for (property in object), etc.

From my perspective it would seem like a hole in the implementation for it
to be missing but that is also due to having such a split of time between
the two languages.  Take for instance python utilizing the same thing:

for variable in expression:
...     code
...

as well as ruby:

for variable [, variable ...] in expression [do]
   code
end

Ultimately, I would feel that having the in operator would also create the
expectation that in PHP we would be able to achieve the following:

for ($var in $array) {} and/or for ($var in $object) {};

Certainly foreach is more rich but I believe based on other languages and
paradigms that this would be something people would request and expect if
the in operator was to make it into PHP 7.

Regards,

Mike

---

## #80874 — Marcio Almada — 2015-01-20T13:47:51+00:00

URL: https://externals.io/message/80850#80874 · In reply to: #80872

Hi,

Mike, the use of "in" as `for ($var in $object) {};` could be the
subject for another distinct RFC since it's doing something different
from the original proposal:

var_dump("PHP" in ["PHP", "C", "Java"]); // true

2015-01-20 10:41 GMT-03:00 Mike Willbanks <pencap@gmail.com>:
> Hello Pierre, Andrea and Niklas,
>
> 
>
> > […]
>
>
> It certainly is the same feature from the foreach perspective.  I'm not
> against leaving it out, however, it would be much like the in operator thus
> providing some additional syntax sugar.  Many people that often program in
> JavaScript are used to having:
> array.forEach(function()),  for (property in object), etc.
>
> From my perspective it would seem like a hole in the implementation for it
> to be missing but that is also due to having such a split of time between
> the two languages.  Take for instance python utilizing the same thing:
>
> for variable in expression:
> ...     code
> ...
>
> as well as ruby:
>
> for variable [, variable ...] in expression [do]
>    code
> end
>
> Ultimately, I would feel that having the in operator would also create the
> expectation that in PHP we would be able to achieve the following:
>
> for ($var in $array) {} and/or for ($var in $object) {};
>
> Certainly foreach is more rich but I believe based on other languages and
> paradigms that this would be something people would request and expect if
> the in operator was to make it into PHP 7.
>
> Regards,
>
> Mike

---

## #80876 — Mike Willbanks — 2015-01-20T14:05:47+00:00

URL: https://externals.io/message/80850#80876 · In reply to: #80874

Hello,

On Tue, Jan 20, 2015 at 7:47 AM, Marcio Almada <marcio.web2@gmail.com>
wrote:

> Hi,
>
> Mike, the use of "in" as `for ($var in $object) {};` could be the
> subject for another distinct RFC since it's doing something different
> from the original proposal:
>
> var_dump("PHP" in ["PHP", "C", "Java"]); // true
>

It is indeed different but ever so slightly, a for loop in this case cannot
handle a single argument of true and would cause a parse error.

Therefore for ("PHP" in ["PHP, "C", "Java"]) could be handled differently.
Again, my main point is that due to other languages the in operator itself
also correlates to for ($var in $container), I understand having an
additional RFC but this is indeed the place for discussion of such things.

Also FYI - in the future please try not to top post and instead post under
where you are commenting as it makes it more difficult for people coming
later to the thread to see the scope of the conversation.

Regards,

Mike



>
> 2015-01-20 10:41 GMT-03:00 Mike Willbanks <pencap@gmail.com>:
> > […]
> wrote:
> > […]
> implementation
> > […]
> be
> > […]
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...in
> > […]
> thus
> > […]
> in
> > […]
> it
> > […]
> the
> > […]

---

## #80877 — Marcio Almada — 2015-01-20T14:10:35+00:00

URL: https://externals.io/message/80850#80877 · In reply to: #80876

Mike,

> Also FYI - in the future please try not to top post and instead post under where you are commenting as it makes it more difficult for
> people coming later to the thread to see the scope of the conversation.

Thanks for the tip! I read to "do not top post" on the guidelines but
had no clue what it meant until now xD

---

## #80878 — Marcio Almada — 2015-01-20T14:27:59+00:00

URL: https://externals.io/message/80850#80878 · In reply to: #80877

Mike,

Back to the subject,:

> It is indeed different but ever so slightly, a for loop in this case cannot handle a single argument of true and would cause a parse error.

> Therefore for ("PHP" in ["PHP, "C", "Java"]) could be handled differently.  Again, my main point is that due to other languages the in
> operator itself also correlates to for ($var in $container), I understand having an additional RFC but this is indeed the place for
> discussion of such things.

Agree, but maybe a RFC for "in" operator and a follow up RFC to allow
"in" on "for" context could be a win/win here as long as one feature
doesn't block each other?


2015-01-20 11:10 GMT-03:00 Marcio Almada <marcio.web2@gmail.com>:
> Mike,
>
> > […]
>
> Thanks for the tip! I read to "do not top post" on the guidelines but
> had no clue what it meant until now xD

---

## #80880 — Rowan Collins — 2015-01-20T15:42:01+00:00

URL: https://externals.io/message/80850#80880 · In reply to: #80852

Mike Willbanks wrote on 20/01/2015 03:30:
> I am very familiar with the in operator.  However,  the implementation
> would be incomplete without handling loops via the in operator.  Many
> people when seeing an in operator also think of JavaScript.  In that case
> the in operator iterates over properties.  As such in PHP we should be able
> to iterate over associative arrays should the syntax be added.
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...in

I don't really see how this is related to the in operator, other than 
that some languages reuse the same keyword for both purposes.

My immediate association when I saw this proposal was not "ah, like the 
loop syntax in JavaScript", but "ah, like the IN() operator in SQL".

Given the ability to write foreach ( $foo as $key => $value ), I'm not 
sure adding a variant syntax of for ( $key in $foo ) has that much value 
for PHP.

Regards,
-- 
Rowan Collins
[IMSoP]

---

## #80881 — Dennis Birkholz — 2015-01-20T15:54:42+00:00

URL: https://externals.io/message/80850#80881 · In reply to: #80880

Am 20.01.2015 um 16:42 schrieb Rowan Collins:
> Given the ability to write foreach ( $foo as $key => $value ), I'm not
> sure adding a variant syntax of for ( $key in $foo ) has that much value
> for PHP.


I totally agree with you here.

The only real reason why Javascript has a for-in operation that iterates
over object properties is the lack of non-integer keys in Javascript arrays.
For PHP iterating over object properties is a very rare case IMHO. So I
would stick with foreach for that case.

Kind regards,
Dennis Birkholz

---

## #80887 — Stanislav Malyshev — 2015-01-20T19:07:09+00:00

URL: https://externals.io/message/80850#80887 · In reply to: #80878

Hi!

> Agree, but maybe a RFC for "in" operator and a follow up RFC to allow
> "in" on "for" context could be a win/win here as long as one feature
> doesn't block each other?

The problem is "in" is not just "for". The problem is this: when you say
"$foo in $bar", is $foo a value or a key? In many languages, $foo would
be a value for a list (and a vector) and a key for a map, but in PHP
lists, vectors and maps are the same data type, so you can not implement
it in the same way as, say, in Python. I.e. in Python:

> > […]
True
> > […]
True
> > […]
False
> > […]
True
> > […]
False


In PHP, even if it'd be possible to implement such semantics (which I'm
not sure), it would be very confusing and hard to explain.

-- 
Stas Malyshev
smalyshev@gmail.com

---

## #80912 — francois@tekwire.net — 2015-01-20T22:30:27+00:00

URL: https://externals.io/message/80850#80912 · In reply to: #80880

> De : Rowan Collins [mailto:rowan.collins@gmail.com]
> 
> Given the ability to write foreach ( $foo as $key => $value ), I'm not
> sure adding a variant syntax of for ( $key in $foo ) has that much value
> for PHP.

+1. Useless and ambiguous.

---

## #81000 — Larry Garfield — 2015-01-22T22:58:06+00:00

URL: https://externals.io/message/80850#81000 · In reply to: #80880

> Mike Willbanks wrote on 20/01/2015 03:30:
> > […]
>
> I don't really see how this is related to the in operator, other than 
> that some languages reuse the same keyword for both purposes.
>
> My immediate association when I saw this proposal was not "ah, like 
> the loop syntax in JavaScript", but "ah, like the IN() operator in SQL".
>
> Given the ability to write foreach ( $foo as $key => $value ), I'm not 
> sure adding a variant syntax of for ( $key in $foo ) has that much 
> value for PHP.
>
> Regards,

I like the idea of a boolean IN.  If nothing else it would simplify the 
common cases for strpos and `in_array()` and friends.  I agree that 
leaving out for/foreach is a good idea as that's a different thing that 
would just so happen to use the same new reserved word. That's fine; 
"use" became reserved for namespaces and then was reused for traits 
without incident.

However, we should also ask what happens with objects.  I've seen a lot 
of people trying to push toward collection objects rather than plain 
arrays for a variety of reasons, and of course we run smack into the 
"PHP has all of these cool array-manipulation functions that are almost 
great for functional programming but don't work on iterators, ah crap" 
problem.

So what would the following do:

$o = new stdclass;
$o->a = 'b';
$o->c = 'd';

print 'a' in $o;

print 'b' in $o;

Or more to the point:

$a = new ArrayObject(['a', 'b', 'c']);
print 'c' in $a;

There are likely lots of implementation details around making it work, 
but it would be lovely if at least some collection objects could support 
IN.  Perhaps an Innable interface? :-)  (Which then an iterator could 
also implement if it made logical sense for it to do so, which is not 
always the case.)

--Larry Garfield

---

## #81014 — Yasuo Ohgaki — 2015-01-23T03:01:42+00:00

URL: https://externals.io/message/80850#81014 · In reply to: #80850

Hi Niklas,



> I'd like to propose a new feature to PHP: The in Operator
> Bob mentioned a few weeks ago he wants such an operator in PHP and today I
> stumbled over
>
> http://nikic.github.io/2012/07/27/How-to-add-new-syntactic-features-to-PHP.html
> again,
> which uses the in operator as a sample.
>
> Use cases:
>
> $obj = new StdClass;
> $obj->prop = "value";
> $languages = ["PHP", "C", "Java"];
> var_dump("PHP" in $languages); // true
> var_dump("Python" in $languages); // false
> var_dump(0 in $languages); // false
> var_dump("0x0" in ["0e3"]); // false
> var_dump("prop" in $obj); // true
> var_dump("foo" in $obj); // false
> var_dump("Hello" in "Hello World!"); // true
>
> For strings, it would replace `strpos("Hello World!", "Hello") !== false)`,
> for arrays it would replace `in_array($needle, $haystack, true)`
> and for objects it would be a replacement of property_exists($class,
> $property)`.
>
> This change would mainly be syntax sugar, but I think it's worth because:
>  * `"0x0" in ["0e3"]` would return false while `in_array("0x0", ["0e3"])`
> returns true, that's probably an edge case, but there may be a lot of
> people that don't use the `$strict` parameter, see http://3v4l.org/0K7E5
>  * It would solve the issue that it's hard to remember the order of the
> arguments for in_array and strpos, just had to look it up again.
>
> Bob would volunteer to implement that feature.
>

I would like to reserve 'in' and 'out' for Design by Contract (DbC).
http://en.wikipedia.org/wiki/Design_by_contract

D language has in and out like

function foo() {
in {
   // precondition
}
out {
  // postcondition
}
{
  // function body
}

Contract programing can be done only with assert or annotation.
However, it's much easier/readable with native language support.
Contract programming is proved to be fast/robust/secure.

in operator can be useful, but it's the same as `in_array()`.
If we need strict type check, we may do

$ php -r 'var_dump(in_array("0x0", ["0e3"], TRUE));'
bool(false)

as you mentioned.

I would like to reserve 'in' for DbC rather than syntax sugar.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #81046 — Rowan Collins — 2015-01-23T14:57:23+00:00

URL: https://externals.io/message/80850#81046 · In reply to: #81014

Yasuo Ohgaki wrote on 23/01/2015 03:01:
> Hi Niklas,
>
> 
>
> > […]
> I would like to reserve 'in' and 'out' for Design by Contract (DbC).
> http://en.wikipedia.org/wiki/Design_by_contract
>
> D language has in and out like
>
> function foo() {
> in {
>     // precondition
> }
> out {
>    // postcondition
> }
> {
>    // function body
> }

Would this conflict? It seems to me that this syntax could only ever 
exist in a declaration (function signature) context, and the proposed in 
operator could only ever exist in a procedural code (function body) 
context, which are surely completely separate sections of the parser.

If anything, wanting the keyword for another purpose might strengthen 
its case, because each feature isn't reserving a new word. It's not the 
first keyword to have distinct meanings by context - "use" means very 
different things for namespaces, traits, and closures.

Regards,
-- 
Rowan Collins
[IMSoP]