By that, I mean just the "regular" form of opIn, and only allow overloading of opIn_r.

Why?  Well, 'in' doesn't make sense if you reverse it; that is, "array in 4" makes no sense while "4 in array" does.

Just from a cursory glance at opover.c, this should not be hard to implement - just have InExp::opId() return NULL.  It doesn't look like anything depends on the result of opId() being non-NULL.

Jarrett Billingsley wrote:

> By that, I mean just the "regular" form of opIn, and only allow overloading of opIn_r.
> 
> Why?  Well, 'in' doesn't make sense if you reverse it; that is, "array in 4" makes no sense while "4 in array" does.
> 
> Just from a cursory glance at opover.c, this should not be hard to implement
> - just have InExp::opId() return NULL.  It doesn't look like anything depends
> on the result of opId() being non-NULL.

I agree


-- 
AKhropov

In article <e7a9gf$119s$1@digitaldaemon.com>, Jarrett Billingsley says...
>
>By that, I mean just the "regular" form of opIn, and only allow overloading of opIn_r.
>
>Why?  Well, 'in' doesn't make sense if you reverse it; that is, "array in 4" makes no sense while "4 in array" does.
>
>Just from a cursory glance at opover.c, this should not be hard to implement - just have InExp::opId() return NULL.  It doesn't look like anything depends on the result of opId() being non-NULL.
>

What if you had a Set class and you wanted to override its opIn's to return something about set membership?  "set in array" and "array in set" both make perfect sense in that case.  One asks if the 'set' is a subset of elements in 'array', the other asks if the elements in 'array' are a subset of 'set'.  If you only have the ability to override methods on your Set class then you'll want both opIn and opIn_r to make that work.

If it doesn't make sense for a particular class then just don't provide the overload.  Same goes for all overloadable operators.