If we aren't going to have standard optimizations and/or a library for making them any time soon, the argument for having the alternative is more compelling.

One advantage of the optimization approach is that it yields faster results without sacrificing language simplicity. If someone was to present something that was an or list the optimization approach would pick that up and use is_in. A SingularOrList is much easier for a naive optimizer to pick up than a series of nested or statements which I would also like to see appropriately converted.

But ultimately it comes down to timing for me. If it's a year or more that we expect to see a generic optimization library/tool for Substrait it's probably not worth waiting for (and we already have multiples of similar concepts today).

I'm missing something. How is is_in less generic than the or list and why do you not map it back to is in on the reverse? They seem logically equivalent to me.

An or list could be something like (f0 == f1) || (f0 == f2)

is_in requires that all of the choices be literals and is often implemented with something like a hash set.

Though, now that I think about it, substrait has no way of restricting function arguments to be literals. So is_in couldn't be well described as a function. You could state that the arguments are constant, which I suppose invalidates an earlier claim I made that "constant" doesn't make sense for scalar functions. I seem to have pretzeled myself.

Ah. An earlier version of or list restricted all the option expressions to literals... I guess we generalized it.