[Issue 1323] Implement opIn_r for arrays

[d-bugmail at puremagic.com]

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





------- Comment #6 from wbaxter at gmail.com  2007-07-09 14:38 -------
(In reply to comment #5)
> How about make
> 
> (i in array)
> 
> go to
> 
> ((i>=0 && i<array.length) ? &array[i] : null)
> 

Whichever meaning it is given it should probably return a useful pointer like
the opIn for AA's does.  But I'd argue the above is pretty useless or at least
brief enough already to not be worth the effort.  Especially since now you've
got a pointer that might or might not be null, so the next thing you're
probably going to do is turn around and check if it's null and if not
dereference it.  So it's like saying:

auto x = ((i>=0 && i<array.length) ? &array[i] : null);
if (x !is null) {
   auto X = *x;
   ...
}
That's just silly when you can instead do
if (i>=0 && i<array.length) {
   auto X = array[i];
}

Do you folks actually have some killer use case for wanting to pretend that
indices are like AA keys?  Or is it just an ideological thing?  Because I
agree, you're totally right on the idealogical front.  We can think of them
both as a map or partial function from one set to another.  Gotcha.  

But it's just not useful.  Like I said, very seldom in my experience are you
ever tempted to throw AA's and regular arrays at the same problem.  You're more
likely to switch an array implementation to a Set implementation of some sort. 
And guess what, if you implement said Set using AA's then you'll be putting the
contents of the arrays in the _keys_, not the values, using a bool[T] or
somesuch.  So if X in Y checks keys for AA's then, in this common use case, it
would be better for "generic code" if X in Y checked the values of the arrays
rather than the indices.


--