> 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 going from the former to the latter doesn't require binary encoding change at all, if the encoding is optimal. Getting from `oneoff (token unit)` to `oneoff (token { linepos })`, depending on the binary encoding format you design, doesn't require you making changes to the parser's runtime, as long as the parser takes into account that `unit` is isomorphic to the zero-arity-product `{}`, and since both `{}` and `{ linepos }` can be presented with a fixed positional addressing, you get your values in a backward-compatible way, but under a specific condition: the parser library API provides `repeated (oneoff )` as a non-materialised stream of values , so that the exact interpretation of happens at a user's calling site, according to the existing stated protocol spec: if it says ` = token`, then `list (repeated (oneoff (token { linepos })))` is isomorphic to `list (repeated (oneoff token))` in the deployed version of the protocol that knows nothing about the line positions, so my endpoints can send you either of:
* Version 0: [len][oneoff_bincode][token_arr]
* Version 1: [len][oneoff_bincode_sum][token_arr][unit]
* Version 2: [len][oneoff_bincode_sumprod][token_arr][prod_arr]
* Version 3: [len][oneoff_bincode_sumprod_sparse][token_arr][presence_arr][prod_arr]