Previous discussions: * https://news.ycombinator.com/item?id=18188519 * …

> I guess I'll, once again, copy/paste the comment I made when this was first posted I had missed it those other times, and it's super interesting. So thank you for copy/pasting it once again :-).

> Real-world practice has also shown that quite often, fields that originally seemed to be "required" turn out to be optional over time how often? as practiced by who, and where? > 2. You actually do not want a oneof field to be repeated! > How do you make this change without breaking compatibility? Now you wish that you had defined your array as an array of messages, each containing a oneof, so that you could add a new field to that message. But because you didn't, you're probably stuck creating a parallel array to store your new field. That sucks. Nice, "explain to me how you're going to implement a backward-compatible SUM in the spec-parser that doesn't have the notions needed. Ha! You can't! Told you so!" > But because you didn't, you're probably stuck creating a parallel array to store your new field. That sucks. Not really, `oneoff token` is isomorphic to `oneoff (token unit)` and …

To me, it seems that version-change-safety and the usefulness of the generated code constitute a design tradeoff: If you mark a field as required, then the generated data structures can skip using Option/pointers, and this very common form of validation can be generated for free. If you disallow marking a field as required, then all fields must be checked for existence, even ones required for a system to function, which is quite a burden and will lead to developers having to write their own types anyway as a place to put their validated data into. If data is required to be present for an app to function, then why can't I be given the tools to express this, and benefit from the constraints applied to the data model? Most of the time when I would like to use a schema-driven, efficient data format and code generation tool, the data contract doesn't change frequently. And when it does, assum…