You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)]structSettings{
a:[0u8;2],// "a = [0, 1]"#[miniconf(defer)]
b:[0u8;8],// "b/1 = 1"}
The text was updated successfully, but these errors were encountered:
As discussed in #96 (comment) we could consider:
Miniconf
andMiniconfAtomic
for the following:impl_single
, blanketimpl MiniconfAtomic for T where T: Serialize + Deserialize
array
and give it atomic supportSerialize + Deserialize
Miniconf
(explicitly or derive) support forarray
,Option
etcMiniconf
support forVec
and others that areIndexMut
+IntoIterator
(?)Miniconf
for things that are container-like: tuples (macro impl up to 32 tuple size) or hashmaps.miniconf(defer)
(modulo bikesheding for a better name:defer
,inner
,non-atomic
) to thederive(Miniconf)
macro. This is along the lines how other crates like e.g.thiserror
achieve fine grained control over derive macros (error(transparent)
etc).Miniconf
impl within the member and make the member non-atomic.MiniconfAtomic
.Miniconf
explicitly in (the rare) cases where this is not an ambiguity problem.derive(Miniconf)
for tuples, enums.array
/String
/Vec
areAtomic
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
andMiniconfAtomic
can/should/need to be disjoint for this.The text was updated successfully, but these errors were encountered: