Hello.

I'm curious as to the reason for why the in operator only works with associative arrays. I am working on a program where having an in operator for a normal array would be useful. eg:

if ("string" in ["string1", "string2", "string3", ...]) {
   do something
}

Is there some other way to do this in the language without resorting to a function or class method call?

Thanks ahead,

Myron Alexander.

On Thu, 26 Apr 2007 01:30:46 +0200, Myron Alexander wrote:

> Hello.
> 
> I'm curious as to the reason for why the in operator only works with associative arrays. I am working on a program where having an in operator for a normal array would be useful. eg:
> 
> if ("string" in ["string1", "string2", "string3", ...]) {
>     do something
> }
> 
> Is there some other way to do this in the language without resorting to a function or class method call?
> 
No. The D programming language does not contain a reserved word or built-in function to scan through an array other than Associative Arrays.

The simplest is just a function call ...

   if (container.contains(elem) == true) {
        // do something
   }

where contains is something along the lines of ...

  bool contains(T)(T[] container,T elem)
  {
     foreach(e; container)
        if (e == elem) return true;
     return false;
  }

Unless you know some details about the internal ordering of the array elements, a simple linear scan is all that can really be done.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
26/04/2007 9:33:19 AM

Myron Alexander wrote:
> Hello.
> 
> I'm curious as to the reason for why the in operator only works with associative arrays. I am working on a program where having an in operator for a normal array would be useful. eg:
> 
> if ("string" in ["string1", "string2", "string3", ...]) {
>    do something
> }
> 
> Is there some other way to do this in the language without resorting to a function or class method call?
> 
> Thanks ahead,
> 
> Myron Alexander.

I've proposed this before.  Maybe others too.  It makes sense.  It's what other languages with an 'in' operator do.  It should work.  It doesn't.  It isn't high on Walter's priority list because it can be worked around easily.

--bb

Derek Parnell wrote:
> No. The D programming language does not contain a reserved word or built-in
> function to scan through an array other than Associative Arrays.

Thanks Derek.

Regards,

Myron Alexander.

Bill Baxter wrote:
> I've proposed this before.  Maybe others too.  It makes sense.  It's what other languages with an 'in' operator do.  It should work.  It doesn't.  It isn't high on Walter's priority list because it can be worked around easily.
> 
> --bb

I suspected as much. Thanks for the info. I add my voice of support for the proposal to expand the in operator to operate on normal arrays.

This is something that would be nice to have, but as you say, the work-around is simple enough.

Thanks,

Myron Alexander.

Myron Alexander wrote:
> Bill Baxter wrote:
>> I've proposed this before.  Maybe others too.  It makes sense.  It's what other languages with an 'in' operator do.  It should work.  It doesn't.  It isn't high on Walter's priority list because it can be worked around easily.
>>
>> --bb
> 
> I suspected as much. Thanks for the info. I add my voice of support for the proposal to expand the in operator to operate on normal arrays.
> 
> This is something that would be nice to have, but as you say, the work-around is simple enough.
> 
> Thanks,
> 
> Myron Alexander.

I don't recall if I ever filed an enh request for it.  If you have time, you could check and see, and then file one if you don't find it there already.

--bb

Myron Alexander wrote:
> Bill Baxter wrote:
>> I've proposed this before.  Maybe others too.  It makes sense.  It's what other languages with an 'in' operator do.  It should work.  It doesn't.  It isn't high on Walter's priority list because it can be worked around easily.
>>
>> --bb
> 
> I suspected as much. Thanks for the info. I add my voice of support for the proposal to expand the in operator to operate on normal arrays.

Agreed. If only because it is expected to work that way, and didn't we learn that breaking expectations is Sin?

In the meantime, a workaround with a comparable functionality as opIn would be

T *has(T)(T[] array, T match) { foreach (inout elem; array) if (elem==match) return &elem; return null; }
void main() { auto a=[0, 1, 2, 3]; if (&a[3] is a.has(3)) writefln("OK"); }

Greetings ^^

inFavor++;

Downs Wrote:
> Myron Alexander wrote:
> > Bill Baxter wrote:
> >> I've proposed this before.  Maybe others too.  It makes sense.  It's what other languages with an 'in' operator do.  It should work.  It doesn't.  It isn't high on Walter's priority list because it can be worked around easily.
> >>
> >> --bb
> > 
> > I suspected as much. Thanks for the info. I add my voice of support for the proposal to expand the in operator to operate on normal arrays.
> 
> Agreed. If only because it is expected to work that way, and didn't we learn that breaking expectations is Sin?
> 
> In the meantime, a workaround with a comparable functionality as opIn would be
> 
> T *has(T)(T[] array, T match) { foreach (inout elem; array) if (elem==match) return &elem; return null; }
> void main() { auto a=[0, 1, 2, 3]; if (&a[3] is a.has(3)) writefln("OK"); }
> 
> Greetings ^^

On Thu, 26 Apr 2007 03:09:46 +0300, Myron Alexander <consulting@myron.RMVETHISalexander.com> wrote:

> I suspected as much. Thanks for the info. I add my voice of support for the proposal to expand the in operator to operate on normal arrays.

Or, better yet, just get fully-working sets (like dynamic arrays but without values). Declared like void[datatype], you could do the same operations as with AA (in, .remove, foreach, etc.), plus .add(element) (the AA syntax won't work here). These would work much faster anyway, at the cost of preserving a certain order and having at most one instance of an element at a time.

-- 
Best regards,
  Vladimir                          mailto:thecybershadow@gmail.com

Bill Baxter wrote:
> I don't recall if I ever filed an enh request for it.  If you have time, you could check and see, and then file one if you don't find it there already.
> 
> --bb

Bill,

I was in the process of writing the enhancement request when I had a quick peek at the documentation. The operator overloading document specifically allows for overloading the in operator with opIn and opIn_r (although doesn't say how it is supposed to be used). This got me thinking, is this an enhancement request, or a bug fix request?

Regards,

Myron.