in operator generalization

[Ivan Senji]

Stewart Gordon wrote:
> Les Baker wrote:
>> Looking through old NG posts I found this one by Ben Hinkle last year
>> about extending the "in" operator to support static/dynamic arrays.
>>
>> http://www.digitalmars.com/d/archives/digitalmars/D/25164
> <snip>
> 
> There are two problems with that proposal:

To reply or not to reply :)

I see that there are two groups of people when it comes to in and
arrays. Much like there are in the bool story.

> 
> 1. At the moment, the only use of the in operator is to determine
> whether a key is present in an AA.  Logically, therefore, for linear
> arrays,
> 
>     x in y
> 
> should report on whether x is an index within the bounds of y, i.e.

One group thinks this is the way it should work.

> 
>     x >= 0 && x < y.length

But that doesn't make any sense. A syntax sugar for this is not needed
because this expression is not that hard to write.

AAs and normal arrays are both called arrays but I see them as
completely different things.

Let's say I'm implementing a word counting program in D.
I could do it like this:

int[char[]] words;
Then for each word words[word]++;


But if I wanted to use normal arrays the one storing words would be:

char[] [] words;
int[] count;

Now I have a word and a common thing would be to find out if it is in
'words'.

I would like to be able to simply write something like:

if( (auto x = word in words) == -1 )
{
  words.length = words.length ++;
  count.length = count.length ++;
}
else
{
  count[x]++;
}

The version of 'in' that would be testing arrays index for range would
never (IMO) be useful/used.


So the problem here is the key-value difference in array-AA.

Arrays:
Value - the interesting part
Key - index, usually not that important

AAs:
Key - the interesting part
Value - some additional information about my key, like number of words,
or any other information associated with the interesting part.


I am interested in the interesting part when it comes both to arrays and
AAs.


But I also understand why Walter is probably never going to add this
potentially useful feature: There will always be those that disagree.



> 
> This has been talked about before:
> 
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/6082
> 
> 
> 2. The result of the in operator is designed to be directly usable as a
> boolean value and to do what it says on the tin when used as such.
> Making it return an index, instead of a pointer as in for AAs does,
> screws this up totally.  As such, under Ben's proposal
> 
>     if (x in y)
> 
> would be equivalent to
> 
>     if (y.length != 0 && y[0] != x)
> 

I don't understand. Are you sure?
Isn't what Ben was suggesting something like:

if(x in y)

is the same as:

int index=-1;

for(int i=0; i<y.length; i++)
{
  if(y[i]==x) {index = i; break;}
}


> which is well and truly counter-intuitive.

Sure is.

But what I wrote above makes sense? Doesn't it? Isn't that what everyone
would expect in for arrays to do?

Actually I don't care that much if it return a pointer or an index.
Pointer might be a bit more useful.

y[x in y] ++; vs. (*(x in y)) ++;


Although this is the way I would expect things to work there seem to be
those thinking that there should be a way to check if there is a certain
value in the associative array. Is this really needed?

Do I really want to know which word has a certain frequency in a text?
Actually I had to do something like that once but I was able to do it by
constructing a reverse AA (For example char[] [int]),
but searching for values in AAs doesn't seem as interesting and useful
as searching for values in normal arrays?