www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The in operator and normal arrays

reply Myron Alexander <consulting myron.RMVETHISalexander.com> writes:
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.
Apr 25 2007
next sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
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
Apr 25 2007
parent Myron Alexander <consulting myron.RMVETHISalexander.com> writes:
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.
Apr 25 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Apr 25 2007
parent reply Myron Alexander <consulting myron.RMVETHISalexander.com> writes:
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.
Apr 25 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Apr 25 2007
parent reply Myron Alexander <dprogramming myron.RMVETHISalexander.com> writes:
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.
Apr 27 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Myron Alexander wrote:

 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?


You can only overload operators on structs and classes (and perhaps 
unions). You can't overload operators purely on built-in types and arrays.

(You /could/ overload it separately for every aggregate type you 
implement, but then it still won't work for arrays of primitive types, 
or arrays of arrays)
Apr 27 2007
parent reply Myron Alexander <dprogramming myron.RMVETHISalexander.com> writes:
Frits van Bommel wrote:

 Myron Alexander wrote:

 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?


 
 You can only overload operators on structs and classes (and perhaps 
 unions). You can't overload operators purely on built-in types and arrays.
 
 (You /could/ overload it separately for every aggregate type you 
 implement, but then it still won't work for arrays of primitive types, 
 or arrays of arrays)


Hello Frits.

I am not sure how to use the in operator. I tried to overload it in a 
class and struct but received a compiler error. This is the code I tried:

struct A {
    int opIn (char[] val) {
       return true;
    }
}

void main () {
    A a = A ();

    if ("hello" in a) {
       printf ("It's alive\n");
    }
}

The compiler error I received:
inop.d(10): Error: rvalue of in expression must be an associative array, 
not A

How do I overload the in operator?

Thanks ahead,

Myron.
Apr 27 2007
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Myron Alexander" <dprogramming myron.RMVETHISalexander.com> wrote in 
message news:f0tona$38c$1 digitalmars.com...

    int opIn (char[] val) {
       return true;
    }


Change it to opIn_r and it will work.  (Personally I think the forward and 
reverse overloads should be switched, but whatever)
Apr 27 2007
parent Myron Alexander <dprogramming myron.RMVETHISalexander.com> writes:
Jarrett Billingsley wrote:

 Change it to opIn_r and it will work.  (Personally I think the forward and 
 reverse overloads should be switched, but whatever) 
 
 


Thanks Jarrett, works now.
Apr 27 2007
prev sibling next sibling parent reply Downs <default_357-line yahoo.de> writes:
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 ^^
Apr 26 2007
parent Dan <murpsoft hotmail.com> writes:
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 ^^
Apr 26 2007
prev sibling parent "Vladimir Panteleev" <thecybershadow gmail.com> writes:
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
Apr 26 2007