A an operator overload for 'in' would be nice.

class Foo
{
bool opContains(char[]) {}
}

Foo f;

if("bar" in f) { }

Patrick Down wrote:

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

Gets my vote. I was thinking of mentioning it several times. Although, I thought of naming it opIn; opContains is good too.

Very cool!

"Patrick Down" <Patrick_member@pathlink.com> wrote in message news:bukqnu$1sio$1@digitaldaemon.com...
>
> A an operator overload for 'in' would be nice.
>
> class Foo
> {
> bool opContains(char[]) {}
> }
>
> Foo f;
>
> if("bar" in f) { }
>
>

I guess if it's an operator "in" makes sense.
But if it's a method "contains" is better...
if ( f.Contains ( "bar" ) ) ...

And personally, I prefer methods rather than bogging a language down with operators. Especially when the operation is not likely to be used in a larger expression, as boolean expressions seldom are.

In article <buktne$217e$1@digitaldaemon.com>, C says...
>
>Very cool!
>
>"Patrick Down" <Patrick_member@pathlink.com> wrote in message news:bukqnu$1sio$1@digitaldaemon.com...
>>
>> A an operator overload for 'in' would be nice.
>>
>> class Foo
>> {
>> bool opContains(char[]) {}
>> }
>>
>> Foo f;
>>
>> if("bar" in f) { }
>>
>>
>
>

"Juan C" <Juan_member@pathlink.com> wrote in message news:bul8ct$2id6$1@digitaldaemon.com...
> I guess if it's an operator "in" makes sense.
> But if it's a method "contains" is better...
> if ( f.Contains ( "bar" ) ) ...
>
> And personally, I prefer methods rather than bogging a language down with operators. Especially when the operation is not likely to be used in a
larger
> expression, as boolean expressions seldom are.

In general I agree, but I think "in" will be widely used, especially if we can overload it.

I vote for opIn, btw. (Call it what it is)

> In article <buktne$217e$1@digitaldaemon.com>, C says...
> >
> >Very cool!
> >
> >"Patrick Down" <Patrick_member@pathlink.com> wrote in message news:bukqnu$1sio$1@digitaldaemon.com...
> >>
> >> A an operator overload for 'in' would be nice.
> >>
> >> class Foo
> >> {
> >> bool opContains(char[]) {}
> >> }
> >>
> >> Foo f;
> >>
> >> if("bar" in f) { }
> >>
> >>
> >
> >
>
>

I don't agree.
Indeed, it looks nice, but that's all.
I will be satisfied if there is 'member' method as Lisp and Prolog.

if(f.member("bar")) { }


"Patrick Down" <Patrick_member@pathlink.com> wrote in message news:bukqnu$1sio$1@digitaldaemon.com...
>
> A an operator overload for 'in' would be nice.
>
> class Foo
> {
> bool opContains(char[]) {}
> }
>
> Foo f;
>
> if("bar" in f) { }
>
>

The main reason for this is to be able to completely emulate the fuctionality of associative arrays.

In article <bukqnu$1sio$1@digitaldaemon.com>, Patrick Down says...
>
>
>A an operator overload for 'in' would be nice.
>
>class Foo
>{
>bool opContains(char[]) {}
>}
>
>Foo f;
>
>if("bar" in f) { }
>
>

I don't really like the double use of 'in' , I doubt this will take but what about renaming it to 'contains'.

char [ int ] hash;

if ( hash contains "element" ) { }

?

C
"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message
news:bulf2p$2u6r$3@digitaldaemon.com...
>
> "Juan C" <Juan_member@pathlink.com> wrote in message news:bul8ct$2id6$1@digitaldaemon.com...
> > I guess if it's an operator "in" makes sense.
> > But if it's a method "contains" is better...
> > if ( f.Contains ( "bar" ) ) ...
> >
> > And personally, I prefer methods rather than bogging a language down
with
> > operators. Especially when the operation is not likely to be used in a
> larger
> > expression, as boolean expressions seldom are.
>
> In general I agree, but I think "in" will be widely used, especially if we can overload it.
>
> I vote for opIn, btw. (Call it what it is)
>
> > In article <buktne$217e$1@digitaldaemon.com>, C says...
> > >
> > >Very cool!
> > >
> > >"Patrick Down" <Patrick_member@pathlink.com> wrote in message news:bukqnu$1sio$1@digitaldaemon.com...
> > >>
> > >> A an operator overload for 'in' would be nice.
> > >>
> > >> class Foo
> > >> {
> > >> bool opContains(char[]) {}
> > >> }
> > >>
> > >> Foo f;
> > >>
> > >> if("bar" in f) { }
> > >>
> > >>
> > >
> > >
> >
> >
>
>

If it's not a mathematical operation it shouldn't be an operator.

In article <bumcqt$1ad8$1@digitaldaemon.com>, C says...
>
>I don't really like the double use of 'in' , I doubt this will take but what about renaming it to 'contains'.
>
>char [ int ] hash;
>
>if ( hash contains "element" ) { }
>
>?
>
>C
>"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message
>news:bulf2p$2u6r$3@digitaldaemon.com...
>>
>> "Juan C" <Juan_member@pathlink.com> wrote in message news:bul8ct$2id6$1@digitaldaemon.com...
>> > I guess if it's an operator "in" makes sense.
>> > But if it's a method "contains" is better...
>> > if ( f.Contains ( "bar" ) ) ...
>> >
>> > And personally, I prefer methods rather than bogging a language down
>with
>> > operators. Especially when the operation is not likely to be used in a
>> larger
>> > expression, as boolean expressions seldom are.
>>
>> In general I agree, but I think "in" will be widely used, especially if we can overload it.
>>
>> I vote for opIn, btw. (Call it what it is)
>>
>> > In article <buktne$217e$1@digitaldaemon.com>, C says...
>> > >
>> > >Very cool!
>> > >
>> > >"Patrick Down" <Patrick_member@pathlink.com> wrote in message news:bukqnu$1sio$1@digitaldaemon.com...
>> > >>
>> > >> A an operator overload for 'in' would be nice.
>> > >>
>> > >> class Foo
>> > >> {
>> > >> bool opContains(char[]) {}
>> > >> }
>> > >>
>> > >> Foo f;
>> > >>
>> > >> if("bar" in f) { }
>> > >>
>> > >>
>> > >
>> > >
>> >
>> >
>>
>>
>
>

But we already have many operators that dont fall into that category.

int opCat (  int x)
int opIndex (  int x)
int opCall ( )
int opApply(int delegate(inout uint) dg)

How about , after this one , no more operators ;).

C


"The Lone Haranguer" <The_member@pathlink.com> wrote in message news:bumed2$1cqp$1@digitaldaemon.com...
> If it's not a mathematical operation it shouldn't be an operator.
>
> In article <bumcqt$1ad8$1@digitaldaemon.com>, C says...
> >
> >I don't really like the double use of 'in' , I doubt this will take but
what
> >about renaming it to 'contains'.
> >
> >char [ int ] hash;
> >
> >if ( hash contains "element" ) { }
> >
> >?
> >
> >C
> >"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message
> >news:bulf2p$2u6r$3@digitaldaemon.com...
> >>
> >> "Juan C" <Juan_member@pathlink.com> wrote in message news:bul8ct$2id6$1@digitaldaemon.com...
> >> > I guess if it's an operator "in" makes sense.
> >> > But if it's a method "contains" is better...
> >> > if ( f.Contains ( "bar" ) ) ...
> >> >
> >> > And personally, I prefer methods rather than bogging a language down
> >with
> >> > operators. Especially when the operation is not likely to be used in
a
> >> larger
> >> > expression, as boolean expressions seldom are.
> >>
> >> In general I agree, but I think "in" will be widely used, especially if
we
> >> can overload it.
> >>
> >> I vote for opIn, btw. (Call it what it is)
> >>
> >> > In article <buktne$217e$1@digitaldaemon.com>, C says...
> >> > >
> >> > >Very cool!
> >> > >
> >> > >"Patrick Down" <Patrick_member@pathlink.com> wrote in message news:bukqnu$1sio$1@digitaldaemon.com...
> >> > >>
> >> > >> A an operator overload for 'in' would be nice.
> >> > >>
> >> > >> class Foo
> >> > >> {
> >> > >> bool opContains(char[]) {}
> >> > >> }
> >> > >>
> >> > >> Foo f;
> >> > >>
> >> > >> if("bar" in f) { }
> >> > >>
> >> > >>
> >> > >
> >> > >
> >> >
> >> >
> >>
> >>
> >
> >
>
>