Use symbol to signal uninitialized message fields about cel-spec HOT 3 OPEN

After discussion with the language council, there are some difficulties with using null:

• There is the above ambiguity when setting a Value field, where null is a legitimate value.
• It will cause confusion with the type checker. The type checker already special-cases null for unset wrapper type fields, but it is difficult to generalize this.

A separate value of checker-time type dyn solves these problems. Note #149 which will let us add a new standard name without invalidating existing programs.

We do not intend to use unset when reading fields, as we'd like to preserve deep select expressions without needing to do a has() check at each level.

Open questions:

• What is the runtime behavior of unset? Things get quite complicated if it's not a value in the language. E.g. it would be hard to explain why we can do MyProto{f: test ? value : unset} but not MyProto{f: [value, unset][test ? 0 : 1]}.
• In particular, what is the runtime type of unset?

from cel-spec.

There is some ambiguity for Value fields: does MyProto { value_field: null } mean unset or set to the null_value option?

This same ambiguity exists in the canonical JSON to proto3 mapping (https://protobuf.dev/programming-guides/proto3/#json). In Proto3, {value_field: null} parses to a Value of kind null_value rather than Value default instance.

Given that the CEL spec matches the conversion from proto3 for primitive wrapper types,

CEL spec:

field selection of an unset message field of wrapper type will evaluate to null

Proto3 JSON spec:

Wrappers use the same representation in JSON as the wrapped primitive type, except that null is allowed and preserved during data conversion and transfer

I'd argue that when converting to proto3, Value (which exists to be a proto representation of JSON) should also match the proto3 JSON behavior and interpret value_field: null as null_value rather than unset.

from cel-spec.

Additionally, the canonical JSON to proto3 mapping notes that JSON null is accepted in message types to mean "default instance", and accepted in list types to mean "empty list".

from cel-spec.