Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redesign atomic/terminal elements #99

Closed
jordens opened this issue Oct 19, 2022 · 0 comments · Fixed by #100
Closed

Redesign atomic/terminal elements #99

jordens opened this issue Oct 19, 2022 · 0 comments · Fixed by #100
Assignees
Labels
enhancement New feature or request

Comments

@jordens
Copy link
Member

jordens commented Oct 19, 2022

As discussed in #96 (comment) we could consider:

  • Maybe we need to split our single trait into Miniconf and MiniconfAtomic for the following:
  • Instead of a macro impl_single, blanket impl MiniconfAtomic for T where T: Serialize + Deserialize
  • That extends MiniconfAtomic support to everything that is deserializable/serializable but makes them terminal/atomic elements.
  • That then also covers array and give it atomic support
  • Would also cover every struct that is Serialize + Deserialize
  • Keep the current custom (inner) Miniconf (explicitly or derive) support for array, Option etc
  • Add (inner) Miniconf support for Vec and others that are IndexMut + IntoIterator (?)
  • Consider (inner) Miniconf for things that are container-like: tuples (macro impl up to 32 tuple size) or hashmaps.
  • Add support for tagging specific struct members with miniconf(defer) (modulo bikesheding for a better name: defer, inner, non-atomic) to the derive(Miniconf) macro. This is along the lines how other crates like e.g. thiserror achieve fine grained control over derive macros (error(transparent) etc).
  • That would allow deferring to the (inner) Miniconf impl within the member and make the member non-atomic.
  • Otherwise and by default a struct member is exposed through its MiniconfAtomic.
  • Maybe allow exposing both the outer and inner Miniconf explicitly in (the rare) cases where this is not an ambiguity problem.
  • (Re)Consider supporting derive(Miniconf) for tuples, enums.
  • This gets rid of the ambiguity of whether array/String/Vec are Atomic or not, i.e. whether they use inner or outer miniconf.

Not completely sure whether this fully maps onto the trait architecture of rust though and whether there are no conflicting trait impls or incompatibilities.
Not sure whether the traits Miniconf and MiniconfAtomic can/should/need to be disjoint for this.

#[derive(Serialize, Deserialize, Miniconf)]
struct Settings {
    a: [0u8; 2],  // "a = [0, 1]"
    #[miniconf(defer)]
    b: [0u8; 8],  // "b/1 = 1"
}
@jordens jordens added the enhancement New feature or request label Oct 19, 2022
@ryan-summers ryan-summers self-assigned this Oct 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants