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.

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?

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

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

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'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

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.

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)

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.

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 ^^

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 ^^

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