Bug 4625 – "in" operator for AAs in SafeD code

Status
RESOLVED
Resolution
FIXED
Severity
enhancement
Priority
P2
Component
druntime
Product
D
Version
D2
Platform
All
OS
All
Creation time
2010-08-11T15:19:00Z
Last change time
2011-07-20T09:34:21Z
Assigned to
sean
Creator
bearophile_hugs

Comments

Comment #0 by bearophile_hugs — 2010-08-11T15:19:01Z
This comes after a short discussion in D.learn, where simendsjo in D.learn has shown few examples. I presume "in" done on an Associative Array currently returns a pointer to remove dual AA lookup in a common situation: auto ptr = x in aa; if (ptr) { // do something with *ptr } else { // do something else } But this code shows that it's hard to accept in SafeD the currently designed "in" operator for associative arrays: void main() { auto aa = [1 : 2]; auto p1 = 1 in aa; aa.rehash; // p1 invalidated by rehashing auto p2 = 1 in aa; aa.remove(1); // p2 invalidated by removal } On the other hand "x in AA" is a basic operation that I need to perform in SafeD code too. I can see two possible solutions, but I like only the second one: ---------------- 1) This first solutions needs two changes at the same time: - "in" done on associative arrays always returns a bool, this is memory safe. - improve the optimizer part of the compiler so it is able to remove most cases of dual lookups in AAs. If the compiler is naive then code like this: if (x in aa) { auto value = aa[x]; // ... } requires two searches inside the hash, the first to tell if the key is present, and the second to find it again and fetch its value. A better compiler (LDC1 is already able to do this) can recognize that the code is performing two nearby key searches with the same key, and it can remove the second one, essentially replacing that code with this one: auto __tmp = x in aa; if (__tmp) { auto value = *__tmp; // ... } If the key is removed or a rehash is performed, the compiler doesn't perform that optimization. This is good in theory, but in practice sometimes there is some distance between the first and second lookup, so I think sometimes the compiler may not be able to optimize away the second lookup. ---------------- 2) So I prefer a second solution that has less demands on the optimizer: - Add to AAs a contains() method that always return a boolean. - In SafeD code Disallow the "in" operator for AAs. So in SafeD code you can use aa.contains(). - Improve the optimizer a bit so it's able to remove some cases of dual lookups in AAs (both in SafeD and non SafeD code).
Comment #1 by bearophile_hugs — 2010-08-26T16:58:40Z
See also bug 4475
Comment #2 by kennytm — 2011-07-20T09:34:21Z
Currently 'in' can be used in @safe function.