Given how public the core DataItem type is, I think that issues #117, #132 and #138 will all need API changes: Neither can DataItem gain another variant CommentedItem { comment_before: String, comment_after: String, item: Box<DataItem>}, nor can ByteString gain a field that tells whether it's a '', a h'' or a b64'' string.
I've briefly tried sprinkling in a few #[non_exhaustive] (which are a breaking API change), but they had the side effect of breaking construction as DataItem::Integer { value: 10, bitwidth: 0 } as that may have missed fields.
I suggest that a single API change be made in which a lot of API is made private (possibly DataItem even turns into a struct so it can have hidden internals). Maybe the breaking change would not even add the features, just change the types so that extensibility is possible. After, things could look like constructors that are more focused on the values:
let item = DataItem::integer(42);
We could still allow setting bit widths etc, but I don't think that it's practically needed often. (It gets set through internal access anyway when deserializing CBOR, but when constructing diagonstic notation programmatically, I don't think it should be the focus of ergonomics).
Thing is: I don't know the typical use of the crate well enough to make a full proposal yet -- I mainly use it to do a full conversion without ever touching intermediate artifacts (yet -- once #132 is in, I'll start reaching in more).
Given how public the core DataItem type is, I think that issues #117, #132 and #138 will all need API changes: Neither can DataItem gain another variant
CommentedItem { comment_before: String, comment_after: String, item: Box<DataItem>}, nor can ByteString gain a field that tells whether it's a '', a h'' or a b64'' string.I've briefly tried sprinkling in a few
#[non_exhaustive](which are a breaking API change), but they had the side effect of breaking construction asDataItem::Integer { value: 10, bitwidth: 0 }as that may have missed fields.I suggest that a single API change be made in which a lot of API is made private (possibly DataItem even turns into a struct so it can have hidden internals). Maybe the breaking change would not even add the features, just change the types so that extensibility is possible. After, things could look like constructors that are more focused on the values:
We could still allow setting bit widths etc, but I don't think that it's practically needed often. (It gets set through internal access anyway when deserializing CBOR, but when constructing diagonstic notation programmatically, I don't think it should be the focus of ergonomics).
Thing is: I don't know the typical use of the crate well enough to make a full proposal yet -- I mainly use it to do a full conversion without ever touching intermediate artifacts (yet -- once #132 is in, I'll start reaching in more).