> DUs would also be very useful. Have you considered it?
Well, if DU is ‘discriminated union’ and not ‘diagnosis undetermined’, we’re literally releasing support for them tomorrow! Although we call them “enums with fields” because everyone needs their own names for things you know… But I totally agree, as someone who’s become pretty infatuated with Rust, I don’t know how I lived without them before!
> I would suggest ability to also generate "builder" variant of structs, where every field is optional
One of the big departures between Protobuf and Slice is that fields in Slice are `required` by default. You can still opt-in to Protobuf-like behavior by marking your fields with a modifier like `tag(2)`, but… it’s opt-in. This would also give you a struct like you described, where you could ‘build’ it piece by piece.
I’ve read similar posts to the one you linked about how dangerous `required` can be, and I understand where they’re coming from. Required fields definitely reduce your flexibility in the future. But as someone who’s been using IDLs for a while, I personally never found myself needing it tbh. And making it opt-in goes a good way towards two of the design goals of Slice:
- It feels natural to anyone who’s programming, and in most languages (especially the cool new ones), fields are ‘required’ by default.
- It’s more explicit. Unless you mark your type nullable, it’s non-null. Unless you tag it with an id, it’s required, etc.
Have your experiences differed; Where you’re frequently removing fields from existing types? Just as an honest question from someone trying to fine-tune their language!