[zigzag312]

> The way we typically see definitions evolving is you'll create a struct with required fields first. Then if you need to augment it later on, you can add tagged fields, in a fully compatible manner.

I think this is spot on. Each data container usually has "core" fields that are unlikely to change. Making core fields required and others tagged, gives you simplicity for former and flexibility for latter fields.

I really appreciate the flexibility of Slice IDL. FlatBuffers has table vs struct types, but that just doesn't offer the same fine control of tagged vs untagged fields.

> But this just lets me plug another cool feature in Slice: `custom`[1] types(shameless, I know :^)). These let you hook your own types (with their own custom encodings) into all our machinery. In Rust, you just implement a trait, in C# you write an extension function.

Can I map multiple custom types to the same C# type? :)

  [cs::type("NodaTime.Instant)]
  custom UnixEpochMinutes

  [cs::type("NodaTime.Instant)]
  custom UnixEpochMilliseconds

or

  [cs::type("long[]")]
  custom Int64ArrayDelta       // delta encoding

  [cs::type("long[]")]
  custom Int64ArrayDoubleDelta // double delta encoding

That would be really useful.

[delaconcha]

> Can I map multiple custom types to the same C# type? :)

Yes that is totally fine. In C# side both would be represented as "long[]", the generated code would use the appropriated encoding for the custom type, as provided by the user methods.

[zigzag312]

That's so awesome! This looks like the most well-designed IDL-based binary serialization format I have ever seen. Well done!