[Issue 1323] Implement opIn_r for arrays

d-bugmail at puremagic.com d-bugmail at puremagic.com
Tue Jul 10 18:55:22 PDT 2007


http://d.puremagic.com/issues/show_bug.cgi?id=1323





------- Comment #10 from wbaxter at gmail.com  2007-07-10 20:55 -------
(In reply to comment #9)
> (In reply to comment #4)
> <snip>
> >> This inconsistency might be undesirable from a generic 
> >> programming POV.
> > 
> > I can't see how.  Arrays and associative arrays are different 
> > beasts.  You can't really generically interchange the two, 
> > regardless of what the behavior of 'in' is, because of other 
> > semantic differences.
> 
> Other than in how you can add/remove elements, are there many differences that
> actually compromise their interchangeability?

Well the biggies to me are 
1) "keys" in a linear array must be of type size_t.
2) "keys" in a linear array must contiguous.
   (You can say you'll put a special value in the slots you're not using, but
the hypothetical built-in 'in' operator for arrays will have no knowledge of
your convention.)

We can represent any set!(T) using an array T[].
We cannot represent all AAs T[K] using an array, because we need two arbitrary
types and arrays only have one.

I can see that it might be nice to be able to write generically:
   if (x in y) 
      return y[x];

But if you really need to write an algorithm that works generically on both
arrays and AAs, you're going to need a whole lot more than that one syntactic
similarity to make it work.  So you might as well include something like the
'contains' functions that Regan posted.

Ok, I can see that pretty much any argument here can be posed either way. 
Here's the way I see it:

LA's as a special case of AA's.
* Special case, only very particular AA's can be implemented using an LA
* Syntactically/theoretically simple -- x in y  means you can say y[x]
* Use case is kind of specialized
    (Only applies if you're treating contiguous size_t's as keys)
* No real need:
    - Checking if an index is in range is already easy (i<A.length).
    - If you need an AA just use an AA.  It's built-in!
      (I believe it's pretty uncommon not to know up front if you'll need to
support discontiguous indexes or not).
* Leads to uninuitive code like 
     assert(2 in ["Hi", "There", "Bob"]);
     (Ask five random beginning programmers if this is true or not...)
* Lacks precedent?  Is there some other language where this is used?

LA's as sets:
* General case -- a set can always be implemented as an LA
* Syntactically non-uniform "x in y"==>"x[y] ok" for AA, but not for LA.
  But then again lots of other syntax is different between AA and LA too:
     ~= doesn't work on AA
     assigning length doesn't work on AA
     .remove, .rehash, .keys, .values don't work on LA
     foo["hi"] doesn't work on an any type of LA
* Plenty of use cases from everyday coding in the trenches:
    char[][] what_we_seek = ["hi", "there", "bob"];
    foreach(w; words) { if(w in what_we_seek) { return true; }
* Useful
    - Checking if a value is in an array is not nearly as easy as checking if
an index is valid for the array.
    - D lacks any sort of built in set or bag, so makes arrays more usable as
"poor man's set/bag"
* Intuitive:  assert("Bob" in ["Jill","Jim","Bob"])
     (Again, ask five random beginning programmers if this is true or not...)
* Has precedent in Python's behavior.


-- 



More information about the Digitalmars-d-bugs mailing list