Confusing 'in' operator behavior

[olofson]

The current implementations of the 'in' operator will either return 'false', or the integer index of the located item. The problem with this is that the index can be zero, which looks a whole lot like 'false' in most cases! As a result, a statement like "if x in y ..." probably doesn't do what's intended, and has to be written as "if x in y != false ...".

We should probably have the 'in' operator return only 'true' or 'false', and move the current behavior to another operator, or a built-in function, such as find() or indexof().

[olofson]

Oh, wait:

                 * NOTE: The 'in' operator does use IN, but it
                 *       translates any non-false return to
                 *       true! (Zero is too similar to false
                 *       for the typical 'in' use cases.)

static inline EEL_xno eel_op_in(EEL_object *o, EEL_value *v, EEL_value *r)
{
    EEL_xno x = eel_o__metamethod(o, EEL_MM_IN, v, r);
    if(x)
        return x;
    if(r->type == EEL_TINTEGER)
    {
        r->type = EEL_TBOOLEAN;
        r->integer.v = 1;
    }
    return 0;
}

So, this is not actually an issue.

And, the EEL_MM_IN metamethod could be used as is for implementing a new 'within' operator, or corresponding built-in function! (This covers part of #93.)