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).
