Comment #0 by christian.s77 — 2007-08-19T17:38:30Z
The in expression can be extended to support things like:
int i;
...
if(i in [1, 2, 3])
or
if(i in [1..5])
or even
enum Color { red, blue, green };
if(i in Color)
It will test for the existence of the element in the container, returning true if the element is found. If the container is a set of integers, the element must be an integer. If the set is a string, the element must be a char..
An !in expression also is welcome.
Obs.: also keep the current in expression for associative arrays, returning a pointer to the element and the opIn and opIn_r.
Comment #1 by bearophile_hugs — 2011-08-20T03:53:18Z
As alternative see bug 6536
Comment #2 by lt.infiltrator — 2014-03-19T20:18:58Z
Since the general sentiment is that using in like this, with different semantics, is a bad idea, should this be closed off?
Comment #3 by simen.kjaras — 2017-09-19T09:52:09Z
It's generally agreed that in's semantics makes this kind of use problematic, and different solution should be preferred. These include std.algorithm.among and canFind.