Use symbol to signal uninitialized message fields

[JimLarson]

We recently had a customer question on how to conditionally set a field, wanting to do something like: MyProto{ my_field: x ? some_value : null }. If the field is scalar, the conditional alternative can be the default value. If there is only one conditionally-set field, the conditional can be lifted up at the cost of duplicating the initialization of the other fields. But for multiple conditionally-set message fields, or lots of duplication, we have no good solution, other than the standard cop-out of an extension function.

Given that we're using null to signal a read from an unset field for wrapper types, we should consider using null for indicating "don't set this field" for message types. We'd have to do some work on the type checker to make this legal.

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

[JimLarson]

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?

[benrafshoon]

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.

[benrafshoon]

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".