IN with a right-hand placeholder that resolves to a Java List will still fail later: this validation passes, but the placeholder is then resolved via OperandFactory.createOperand(...), which currently doesn't support List values (it throws UnsupportedOperationException). Consider either extending placeholder resolution to wrap list values into a ListOperand (and map values into MapOperand if needed), or special-casing IN placeholder resolution to build Exp.val(resolvedList) directly so $.bin in ?0 works when ?0 is a list.

inferInTypes currently forces the right operand BIN_PART to Exp.Type.LIST unconditionally. This overwrites an explicitly provided type (e.g. $.x.get(type: INT)) and can mask user errors. Suggest only auto-setting LIST when the right bin type is not explicitly set; if it is explicitly set and not LIST, fail fast with the same parse exception used elsewhere for invalid IN right operands.

placeholderAsRightOperand currently calls parseFilterExp(ExpressionContext.of("$.name in ?0")) without providing PlaceholderValues. In the existing placeholder tests, missing values causes a parse failure (PLACEHOLDER_OPERAND is unsupported when values are null), so this test will fail. Either provide placeholder values here (ideally a List value once placeholder list support is implemented) or change the test to assert the expected exception for missing placeholder values.

The addition of LIST_TYPE_DESIGNATOR as an alternative in the listConstant rule appears unrelated to the IN operation support. The LIST_TYPE_DESIGNATOR token (defined as '[]' on line 417) is already used in the listPart rule for path operations. Adding it here would allow '[]' to be parsed as a list literal, but there are no tests demonstrating this functionality or explaining its purpose in relation to the IN operation. Consider removing this addition if it's not needed for the IN operation, or add tests and documentation if it's intentional.

This is done to handle empty list, added a comment

The inferTypeFromListElements method only checks the first element of the list to infer the type. This could lead to incorrect type inference if the list contains mixed types (e.g., [1, "string", 2]). While Aerospike may not support heterogeneous lists, consider adding a comment explaining this assumption or validating that all elements are of the same type to prevent silent type mismatches.

For IN, type compatibility between the left operand and the list element type is not validated when the left side has an explicit type (e.g. $.name.get(type: STRING) in [1,2] will currently parse/build an expression). Consider inferring the element type for LIST_OPERAND right-hand sides and calling validateComparableTypes() against the left operand type (at least when left is a BIN_PART with an explicitly set type), so mismatches fail fast like other comparison operators.

createOperand() wraps any Map in a TreeMap, which will throw a ClassCastException at runtime if the map keys are not mutually comparable (or if mixed key types are present). Since this method is used for resolving placeholders, it would be better to fail deterministically with a DslParseException/UnsupportedOperationException that explains the requirement (or only accept SortedMap and reject other Map inputs).

Adding IN as an alternative in the mapKey rule (and using ctx.IN() in MapKey.from()) is correct. However, MapKeyRange and MapKeyList (which also use mapKey) have not been updated to handle the IN token. When the IN keyword is used as a key in a range expression (like $.mapBin.{in-z}) or a key list ($.mapBin.{in,z}), the existing code in MapKeyRange.from() and MapKeyList.from() will throw a NullPointerException because it only checks for NAME_IDENTIFIER() and QUOTED_STRING(), not IN(). These classes should be updated with the same fix applied to MapKey.from() in this PR.

inferTypeFromListElements() enforces homogeneous element types, but it’s only invoked via inferLeftBinTypeFromList(), which returns early unless the left operand is BIN_PART. As a result, expressions like "x" in [1, "y"] or ?0 in [1, "y"] won’t throw, while $.bin in [1, "y"] will—this is inconsistent with the stated rule and the negative tests. Consider validating LIST_OPERAND element types for all IN expressions (even when the left isn’t a bin) and add a test that covers a non-bin left operand with a mixed-type list.

The Javadoc says this validation happens "so that the error message references the placeholder index", but the thrown message doesn’t include the index (it’s the same for any placeholder). Either include the placeholder index in the exception message (e.g., ?0) or adjust the Javadoc to match the current behavior.

The Javadoc for validateInPlaceholderValue says it throws DslParseException when the placeholder value is not a list, but placeholderValues.getValue(index) can also throw IllegalArgumentException when the placeholder index is missing. Consider documenting that behavior here (or wrapping it into a DslParseException) so callers/tests don’t see an unexpected exception type.

For IN, the right operand is required to evaluate to a LIST, but inferInTypes() only enforces this for BIN_PART (and PATH_OPERAND when a path function has an explicit non-LIST type). Plain PATH/VARIABLE operands with no explicit type info are always accepted, which means ListExp.getByValue(...) can be built over operands whose inferred/default type is not LIST (e.g., nested map paths default to STRING). Consider either requiring an explicit LIST type on PATH/VARIABLE right operands (e.g., .get(type: LIST) / designator) or coercing the right operand’s type metadata to LIST when used with IN, so validation and generated Exp types align with the operation contract.

The fallback UnsupportedOperationException message became less actionable (it no longer tells callers which operand value types are supported). Consider restoring the previous detail or switching to a DslParseException with a clearer guidance message, since this error can surface for placeholder values at runtime.

Irrelevant for now