Introduce first-class support for optional values within CEL to address the following use cases:

• Conditionally provided variables to CEL expressions
• Conditional field selections with support for alternative values upon absence
• Conditionally set fields based on the presence of an optional value.

Currently, users have to write potentially deeply nested ternary operators using the has macro to determine whether a field is set, to obtain the value, and to return an alternative value.

{ "int_value" : has(data.int_value) ? data.int_value : dyn(null) }

The expression above then has a further problem in that the 'null' return is intended to indicate an optional return value, but doing so requires the use of 'dyn' which obscures the type information from subsequent checks.

• Introduce a type-safe option for indicating an optional value.
• Provide a simple UX for selecting among alternative values, including defaults.
• Simplify the creation of map and message objects with optional field values.
• Minimize syntactic changes as these are hard to version and flag-guard.

• Provide an exact replica of what is exposed java.util.Optional or absl::optional implementations.
• Provide the optimal syntactic experience for working with optional values

Introduce a new opaque type called optional, a small set of syntax changes, and namespaced functions for the instantiation of parameterized optional values:

// select semantics
has(msg.field) ? optional{msg.field} : optional.none()

// map key semantics
key in map ? optional{map[key]} : optional.none()

// list index semantics
index >= 0 && index < list.size() 
    ? optional{list[index]} : optional.none()

// optional field set semantics pseudo-code.
<expr>.hasValue() ? Msg{field: <expr>} : Msg{}

// optional key set semantics
<expr>.hasValue() ? {key: <expr>} : {}

This proposal also recommends that support be added for chaining optional field selection and indexing where selection / indexing on an optional value produces another optional value. This means that the '?' is a viral choice that causes subsequent lookups to produce optional values as well. The intent here is to ensure that nested optional value checks, the common case, are succinct and easy to read:

msg.?map_field[key][0].subfield
msg.?map_field[?key][0].subfield
msg.?map_field[?key][?0].subfield

has(msg.map_field) 
    && key in msg.map_field  
    && 0 < msg.map_field[key].size()  
    && has(msg.map_field[key].subfield)
    ? optional.of( 
        msg.map_field[key][0].subfield) 
    : optional.none())

msg.?map_field[key][0].subfield.orValue("hello world").size()

Since the optional selection behavior should propagate from parent to child select / index expressions the checker will be updated to support the standard select (a.b) behavior over optional objects, and overloads for the index operators (map[value], list[index]) will be created to support indexing on such values.

The following functions are needed to support interoperability with the proposed operators and syntax changes:

// overload: optional_of_value
optional.of(T) -> optional(T)

// overload: optional_ofNonZeroValue_value
optional.ofNonZeroValue(T) -> optional(T)

// overload: optional_none
optional.none() -> optional(T)

// operator: equals
optional(T) == optional(T) -> bool

// overload: optional_select_optional_field
optional(T).?field -> optional(type(T.field))

// overload: select_optional_field
T.?field -> optional(type(T.field))

// overload: list_index_optional_int
list(T)[?int] -> optional(T)

// overload: optional_list_index_optional_int
optional(list(T))[?int] -> optional(T)

// overload: map_index_optional_value
map(K, V)[?K] -> optional(T)

// overload: optional_map_index_optional_value
optional(map(K, V))[?K] -> optional(V)

The new optional values will also have the following member functions to assist with chained operations and testing whether the optional has a value:

// overload: optional_or_optional
optional(T).or(optional(T)) -> optional(T)

// overload: optional_orValue_value
optional(T).orValue(T) -> T

// overload: optional_value 
optional(T).value() -> T // error if none()

// overload: optional_hasValue
optional(T).hasValue() -> bool

With the methods proposed, the original CEL expression is simplified and provides a clear, strongly-typed optional(int) result type which also provides better assurances about the presence of the first UserID mentioned in the original expression:

{ ?"int_value" : data.?int_value }

The new functions make it possible to express whether a value is optional; however, they pose a different challenge when it comes to consuming optional values within message / map creation statements and in 'let'-style expressions which have been implemented in a few different contexts. The following macros will also be introduced to assist with conditionally adapting optional values:

optional(T).optMap(T var, T -> U) -> optional(U)

optional.of(some.field.path)
    .optMap(value, value == x || value == y)

(has(some.field.path)  
    ? [some.field.path].map(value,  
          optional.of(value == x || value == y))[0] 
    : optional.none())

optional(T).optFlatMap(T var, T -> optional(U)) -> optional(U)

optional.of(msg.field[key])
    .optFlatMap(value, value == null
        ? optional.none()  
        : optional.of(value))

(has(msg.field[key])  
    ? [some.field.path].map(value, value == null  
        ? optional.none()  
        : optional.of(value))[0] 
    : optional.none())

A strict implementation of java.util.Optional or absl::optional is not desired since it ties the CEL implementation to a single particular flavor of optional value.

Note, if the has() macro were updated to expand index calls into 'index' in value, then has() would be more broadly useful than it is presently and the semantics more simply expressed as a series of nested has() calls over a field path.

As a potential further improvement in the common case, an operator such as ?? could be considered to simplify expressions such as a.?b.orValue('hello world') to a.b ?? 'hello world'. While this is more succinct, it's not clear how common users will need to leverage optional values. At present, there are a number of cases where the optional introduces optional field proto semantics where they had otherwise been lacking in CEL. With more experience and knowledge about the kinds of use cases this feature opens up, we will be able to better determine which changes will best serve CEL users.

Feature flags will need to be introduced to manage exposing new functions and new syntax to existing CEL applications. However, all changes are forward compatible with previously compiled CEL expressions.

All stacks may initially support this feature by implementing the abstract "optional" type, functions, and macros. The bulk of the risk comes from the syntactic changes as they also have implications for type-checking and introduce new overloads for existing operators.