The Lone Haranguer wrote:
> If it's not a mathematical operation it shouldn't be an operator.
> 

Why?

Besides, set theory has an 'in' operator.  I don't think the symbol it uses is a part of normal ASCII, though.

 -- andy

Patrick Down wrote:
> A an operator overload for 'in' would be nice.
> 
> class Foo
> {
> bool opContains(char[]) {}
> }
> 
> Foo f;
> 
> if("bar" in f) { }
> 
> 

I don't think that is possible as in is not used as operator but keyword for contracts. It would make parsing d sources more complicated. Remember:
in {}
out(result){}
body{}

Such an operator would be nice, but it should use another identifier.
Looking at my keyboard one solution could be '@'

if ("bar" @ f) {}

What do you think

In article <bumklq$1nfm$1@digitaldaemon.com>, Stephan Wienczny says...
>
>Patrick Down wrote:
>> A an operator overload for 'in' would be nice.
>> 
>> class Foo
>> {
>> bool opContains(char[]) {}
>> }
>> 
>> Foo f;
>> 
>> if("bar" in f) { }
>> 
>> 
>
>I don't think that is possible as in is not used as operator but keyword for contracts. It would make parsing d sources more complicated. Remember:

'in' is also used for associative arrays.  Read the documentation: http://www.digitalmars.com/d/arrays.html

>in {}
>out(result){}
>body{}
>
>Such an operator would be nice, but it should use another identifier. Looking at my keyboard one solution could be '@'
>
>if ("bar" @ f) {}
>
>What do you think
>

"Patrick Down" <Patrick_member@pathlink.com> wrote in message news:bun2pp$2e60$1@digitaldaemon.com...
> 'in' is also used for associative arrays.  Read the documentation: http://www.digitalmars.com/d/arrays.html
>

Hmm.  I've forgot it!
Indeed, 'opContains' should be supported.
I agree.

"Stephan Wienczny" <wienczny@web.de> wrote in message news:bumklq$1nfm$1@digitaldaemon.com...
> Patrick Down wrote:
> > A an operator overload for 'in' would be nice.
> >
> > class Foo
> > {
> > bool opContains(char[]) {}
> > }
> >
> > Foo f;
> >
> > if("bar" in f) { }
> >
> >
>
> I don't think that is possible as in is not used as operator but keyword
> for contracts. It would make parsing d sources more complicated. Remember:
> in {}
> out(result){}
> body{}

Even if that is so - and I have to question how it is already managed for ass arrays if it's too hard - I think it's worth it.

> Such an operator would be nice, but it should use another identifier. Looking at my keyboard one solution could be '@'
>
> if ("bar" @ f) {}
>
> What do you think

Not much