Proposal - disallow overloading of opIn

[Bill Baxter]

In article <e7a9gf$119s$1 at 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.