[Issue 1323] Implement opIn_r for arrays

d-bugmail at puremagic.com d-bugmail at puremagic.com
Tue Jul 10 09:50:30 PDT 2007


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





------- Comment #9 from smjg at iname.com  2007-07-10 11:50 -------
(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?

For example, suppose you want a function that iterates over the keys and
values, and possibly changes some of the values it encounters.  This is already
something that can be done for LAs and AAs alike with the same code.

> And note that currently they certainly behave very differently 
> regarding how 'in' works,

Associative arrays: in checks if the key is there
Linear arrays: in doesn't work at all

So why is this an issue?

> and there hasn't been a meltdown because of the lack of 
> ability to generically interchange arrays and associative 
> arrays on account of that.

That doesn't mean it won't happen.

Suppose you want a container indexed by non-negative integers, and a moderate
proportion of indexes within some range will actually have some useful value on
the other end.  You could use an AA, or you could use an LA and fill in the
blanks with ValueType.init or something (which might be more efficient).  At
some point you change your mind about which to use.  You're going to need to
change some code anyway, and the compiler would likely catch quite a few
instances.  But if in does something semantically completely different because
you've changed the internal data structure, it could easily lead to bugs.

<snip>
>> Besides, if we're going to have an operator to check whether 
>> a specified _value_ is in an array, shouldn't it be available 
>> for AAs as well?
> 
> Yes, it would be spelled "foo in AA.values".

Yes, you have a point there.  The .values property could even be defined for
LAs to just return the array, which would enable values of either to be
searched in the same way....

<snip>
> And really the actual implementation of the latter should 
> probably be a little more complex to dance around the ticking 
> time-bomb behavior of == for classes.  Something like:
> bool contains(T[] A, T k) {
<snip>
> }

That depends on whether it's implemented using templates or TypeInfo.  But
TypeInfo_C.equals should probably be changed to do take nulls into account. 
After all, TypeInfo_C.compare already does take null references into account.


-- 



More information about the Digitalmars-d-bugs mailing list