I have encountered unexpected behavior with optional fields in struct literals while using CEL .
The issue revolves around how keys are interpreted in struct literals, specifically with respect to optional fields.
{name: 1}: In this case, the key name is treated as an identifier, leading to its resolution from the environment variable. The resulting output is {/groups/acme.co/documents/secret-stuff: 1}.
{["name"]: 1}: In this example, ["name"] is explicitly quoted, indicating a constant string key. This results in {[name]: 1}, it surrounds the key with square brackets.
The behavior raises concerns about ambiguity when wanting to use a variable as a key. While CEL treats unquoted keys as identifiers and quoted keys as constant strings, it might be beneficial to have clearer guidelines or options for handling such scenarios.
I have encountered unexpected behavior with optional fields in struct literals while using CEL . The issue revolves around how keys are interpreted in struct literals, specifically with respect to optional fields.
I get following output
{name: 1}
: In this case, the key name is treated as an identifier, leading to its resolution from the environment variable. The resulting output is{/groups/acme.co/documents/secret-stuff: 1}
.{[name]: 1}
: returns{[/groups/acme.co/documents/secret-stuff]: 1}
.{["name"]: 1}
: In this example, ["name"] is explicitly quoted, indicating a constant string key. This results in{[name]: 1}
, it surrounds the key with square brackets.The behavior raises concerns about ambiguity when wanting to use a variable as a key. While CEL treats unquoted keys as identifiers and quoted keys as constant strings, it might be beneficial to have clearer guidelines or options for handling such scenarios.