Unary tests behave different when evaluated directly or via an expression using the keyword "in"

[till-stadtler]

Describe the bug
The following unary test, which in itself does not make a lot of sense, behaves differently when being evaluated as a unary test and when being evaluated via an expression using the keyword "in":

Input value: 5
Unary test: not(7)
// returns: true
// expected: true

Expressions: 5 in not(7)
// returns: false
// expected: true

Further examination:
In a unary test, not() is evaluated after the evaluation of the given unary test. In an expression, not() is only used to negate a boolean. It seems that the expression 5 in not(7) is evaluated as 5 in null.

To Reproduce
Steps to reproduce the behavior:
Enter the expressions above in the FEEL Playground.

Expected behavior
Unary tests and expressions using the keyword "in" should behave the same.

Environment

• FEEL engine version: 1.17.3
• Affects:
  • Zeebe: 8.3.3

[saig0]

not() is a special case because it is ambiguous.

• not() for unary-tests
• not() as a built-in function

@till-stadtler do you see other examples that don't use the not() function?

[till-stadtler]

@saig0, no, I have not found any other examples for expressions with "in" and unary tests behaving differently.

So, regarding this bug ticket, when not() is used after "in" in an expression, it should be the not() for unary-tests, but currently is evaluated as not() as a built-in function?

[saig0]

I have not found any other examples for expressions with "in" and unary tests behaving differently.

Thank you for checking. 👍 So, we can make the issue more concrete and focus on the combination of .. in not(..)

when not() is used after "in" in an expression, it should be the not() for unary-tests, but currently is evaluated as not() as a built-in function?

Currently, it uses the not() boolean built-in function.

The expected behavior is unclear. From the FEEL grammar, in is followed by a positive unary test that doesn't include not() from the unary tests.

To do:

• Scan the DMN specification for the usage of in
• Check the DMN TCK for test cases