in not working for arrays is silly, change my view

[Steven Schveighoffer]

On 2/29/20 2:38 PM, JN wrote:
> assert(1 in [1, 2, 3]);
> 
> Error: incompatible types for (1) in ([1, 2, 3]): int and int[
> 
> Yes, I know about .canFind(), but this is something that trips people 
> over and over.
> 
> I think it would be better if "in" worked for both assoc arrays and 
> normal arrays, or didn't work at all, for added consistency.

1. in is supposed to be O(lg(n)) or better. Generic code may depend on 
this property. Searching an array is O(n).
2. Array elements are not guaranteed to be comparable. AA keys are.
3. As this cannot be done via library, the compiler would have to do it 
(at least process the syntax), we need to ensure its something we want 
to do. I don't see it adding much to the language.

What MAY be a good idea is to have a specialized error telling people to 
import std.algorithm.canFind and use it when they try this.

Another thing that may be useful is having something like "isIn" instead 
of "canFind", which swaps the left and right parameters to read more 
naturally.

assert([1,2,3].canFind(1));
vs.
assert(1.isIn([1, 2, 3]));

I'd also add an overload to allow:

assert(1.isIn(1, 2, 3));

-Steve