What is the correct way in proto3 to use HasField?

Originally came up in #1329. HasField with proto3 fails on simple / singular / non-message fields.

@nathanielmanistaatgoogle Mentioned that @haberman might be able to shine some light. Josh, what should we be doing here? The current approach isn’t great:

    # NOTE: As of proto3, HasField() only works for message fields, not for
    #       singular (non-message) fields. First try to use HasField and
    #       if it fails (with a ValueError) we manually consult the fields.
    try:
        return message_pb.HasField(property_name)
    except ValueError:
        all_fields = set([field.name for field in message_pb._fields])
        return property_name in all_fields

---

Should we bother with checking “has field”, e.g.

if _has_field(key_pb.partition_id, 'dataset_id'):
    ...

or should we instead just check Truth-iness

if key_pb.partition_id.dataset_id:
    ...
# OR MORE STRICT
if key_pb.partition_id.dataset_id != '':
    ...

[haberman]

I think the question is: what are you trying to do? Why is it relevant to you whether a field is set or not and what do you intend to do with this information?

In proto3, field presence for scalar fields simply doesn’t exist. Your mental model for proto3 should be that it’s a C++ or Go struct. For integers and strings, there is no such thing as being set or not, it always has a value. For submessages, it’s a pointer to the submessage instance which can be NULL, that’s why you can test presence for it.

Please don’t access msg._fields. It’s a private variable with no defined semantics.

[marshallma21]

Suffering the same pain with @TheJKFever . Can’t tell whether it’s a ENUM value with 0 or not receiving at all.

The funny thing is that, if you convert the proto to json string, you can actually tell whether the field exists or not. So the proto3 actually knows the existance of a Field, but it refuse to provide a way to tell that.