01:01 <isd> fr33domlover: it's an interesting design. The bit for struct fields would be easy to graft on at the schema layer just with some annotations, which would default to `optional` and could be recognized by specific code generator plugins. It's less clear to me how to integrate it into capnp's unions.

01:03 <isd> I'm a bit wary of the design though: it maybe makes sense if you ultimately control all the relevant software and just need to deal with non-atomic/incremental rollout. But if this is used by other people's apps, you probably still don't want to lean on the ability to eventually remove things very often, and I kinda worry about this pushing folks towards breaking compatibility.

01:06 <isd> It's a bit alien coming from a Haskell/ML perspective, but I've found in most cases, the way capnp wants to do schema evolution works pretty well and makes it not hard to maintain backwards compatibility.

01:15 <isd> ...Note that with the parsed capnp api, it's already pretty much safe, in that it both forces the writer to fill in all fields, and forces the reader to handle the "unrecognized" case.

01:19 <isd> I'm a little suspicious of their approach to evolving sums, and would like to see a less contrived example. The error/auth error thing feels like bad design, where probably what I'd do in capnp is just extend error into a group with a type field, in addition to the message. Which would be cleaner than having a generic fallback field. But obviously that's one case; I'd like to see a more compelling use case.