Re: Operators Questions

[adam@irvine.com (Adam Beneschan)]

mheaney@ni.net (Matthew Heaney) writes:
 
 >Language designers: any reason overloading of "in" is too difficult for
 >inclusion in the language?  Why can't you do this already?  This exclusion
 >of the ability to overload "in" seems rather odd and unexpected.

It's not really odd, since overloading pertains to operators, and "in"
isn't an operator.  The overloadable operators all take one or two
expressions as arguments (loosely speaking); "in" takes an expression
on the left and a range or type mark on the right.

This doesn't mean "in" couldn't be overloaded, if this feature were
really desired in the language; but making the compiler handle this
wouldn't be as simple as adding "in" to its list of overloadable
operators.  Suppose the compiler sees

    A in B

where A and B are variables; it would have to look ahead and see if
the next lexeme is ".." to determine whether "in" is being used as a
membership test or as an overloadable operator with A and B as
arguments.  I'd bet that most compilers would need extra code to
handle this case, unless perhaps they're already treating ".." like an
operator internally.  Even worse: Would "in" have a higher or lower
precedence than, say, "+"?  If higher, the compiler would have a nasty
time dealing with both

    A in B + C                which means (A in B) + C

and 

    A in B + C .. D + E       which means A in (B+C)..(D+E)

How far ahead does the compiler have to look to determine what
operator applies to what arguments? 

In any case, it appears that the benefit would not be worth the cost.

                                -- Adam