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.
As alternative see bug 6536
Since the general sentiment is that using in like this, with different semantics, is a bad idea, should this be closed off?
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.