null-safe operator should detect target type as primitive #65098
Labels
>bug
:Core/Infra/Scripting
Scripting abstractions, Painless, and Mustache
Team:Core/Infra
Meta label for core/infra team
Comments
jdconrad
added
>bug
:Core/Infra/Scripting
|
Pinging @elastic/es-core-infra (Team:Core/Infra) |
|
I've added this issue under discuss because I'd like to think through whether or not the second case is worth handling at compile-time. |
jdconrad
added a commit
that referenced
this issue
Nov 16, 2020
…65099) This reverts a change where null-safe was enhanced to cause a compile-time error instead of a run- time error when the target value was a primitive type. The reason for the reversion is consistency across def/non-def types and versions. I've added a follow up issue to fix this behavior in general (#65098).
jdconrad
added a commit
that referenced
this issue
Nov 16, 2020
…65099) This reverts a change where null-safe was enhanced to cause a compile-time error instead of a run- time error when the target value was a primitive type. The reason for the reversion is consistency across def/non-def types and versions. I've added a follow up issue to fix this behavior in general (#65098).
jdconrad
added a commit
that referenced
this issue
Nov 16, 2020
…65099) This reverts a change where null-safe was enhanced to cause a compile-time error instead of a run- time error when the target value was a primitive type. The reason for the reversion is consistency across def/non-def types and versions. I've added a follow up issue to fix this behavior in general (#65098).
|
We should do this after #61388 |
|
After considering this for many years, the benefits don't outweigh the large time investment that would be necessary, so closing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When we use the null-safe operator in Painless, we ignore the target type. This means that we may not know a null-safe operator is invalid until run-time when we could instead know at compile-time.
Take the following scripts:
<1>
params?.test && ...<2>
params?.test.value && ...<1> We know
testmust be abooleanprimitive, so in this case the error should occur at compile-time to inform the script author of the invalid use of a null-safe operator.<2> We know
valuemust be abooleanprimitive, so in this case the error should occur at compile-time to inform the script author of the invalid use of a null-safe operator as well. However, to handle this case appropriately information must be returned during the semantic phase to inform the node handlingvaluethere is at least one null-safe operator used as part of this variable/field chain.The text was updated successfully, but these errors were encountered: