Issue 1323

[Peter Alexander]

On 9/01/11 4:28 PM, Pelle wrote:
> On 01/09/2011 03:07 AM, Robert Clipsham wrote:
>> I'd be all for this, except it's inconsistent.
>> ----
>> auto arr = [ "foo" : 1, "bar" : 2 ];
>> assert("foo" in arr);
>> ----
>> in for associative arrays works by key, if it works by value for normal
>> arrays it's inconsistent, and if it works for keys people will wonder
>> why it's not working as expected.
>
> No, people will not wonder about that. See also: python. Seriously
> people, stop giving this as a reason.

The inconsistency doesn't just affect readability, it's an issue of 
generic programming, too.

e.g.

bool containsAny(R1, R2)(R1 haystack, R2 needles)
{
   foreach (needle; needles)
     if (needle in haystack)
       return true;
   return false;
}

For hashtables, containsAny would look up keys, and for arrays it would 
look up values, which might not be obvious to the user of containsAny.

Also, I'm of the opinion that T[] should be replaceable with T[size_t] 
in most cases, and the differing semantics of 'in' would break that.

string[int] days1 = [0: "Sunday", 1: "Monday", ... ];
string[] days2 = ["Sunday", "Monday", ... ];

assert( days1[6] == "Saturday" ); // pass
assert( days2[6] == "Saturday" ); // pass

assert( "Saturday" in days1 ); // fail
assert( "Saturday" in days2 ); // pass

Personally I think that the semantics of 'in' for AAs should change to 
use values, but I doubt that's going to happen at this stage (if ever).