>>> (This isn't just an academic problem - the problem of trying to evolve fields over time is the reason why Protobufs got rid of the idea of a "required" field.)
if this is the reason of the drop of the required field it doesn't seems smart to me.
They are conflating the definition of a scheme with the scheme evolution logic.
And there are multiple ways to deal with the latter (like adding a schema version, for instance)
Some "required" fields in very commonly used protos ended up being unused, but everybody has to fill them out all the time. If they didn't, the proto wouldn't even parse, by design.
Protobufs explicitly do not have a built-in version system (though of course you could add an optional field for it), presumably because it is better to inspect the data than build in assumptions that a certain version overs a certain invariant.
I don't have a very strong opinion about that change specifically. I think they could have kept their cake and ate it too by solving the schema evolvability some other way, but I also suspect those other ways will come with tradeoffs that are also not pleasant.
But, the point is schema evolvability is a real problem, and it's often not one that a lot of engineers give a lot of thought to, even those who live in very strict statically-typed worlds.
if this is the reason of the drop of the required field it doesn't seems smart to me.
They are conflating the definition of a scheme with the scheme evolution logic.
And there are multiple ways to deal with the latter (like adding a schema version, for instance)