- New type pattern
- Box, Arc, Rc, Vec, Option
FromIterator
cannot be implemented forOption<T>
so#[knuffel(child, unwrap(_))]
approach can't be used
- Semantic difference between structs with and without fields (unit/tuple structs)
- Enum variants with single
Decode
element without attribute vs variants with single scalar element with attribute - Do we need
arguments
/properties
/children
? Is there a case where a type can be used for both patterns? - Lack of documentation about tuple structs
- Enum variants with single
#[knuffel(child, unwrap(children(name)))]
plugins: Vec<String>
instead ofVec<Plugin>
doesn't work?- Are there any possible uses of generics?
definition | attribute ( #[knuffel(_)] ) |
field/variant ( T : DecodeScalar ,U : Decode ) |
examples of X |
input → output | reference | ||||
---|---|---|---|---|---|---|---|---|---|
field mode |
name | decode mode |
unwrap | doc | impl | ||||
unit struct | - | X | - | - → Default::default() |
|||||
struct | - | X | - | - → Default::default() |
|||||
argument |
- | - | - | T |
- | ||||
bool TODO |
|||||||||
Option<T> |
|||||||||
str |
X : FromStr |
SocketAddr , PathBuf |
|||||||
bytes |
X : TryInto<Vec<u8>> |
Vec<u8> |
|||||||
arguments |
- | - | - | X : FromIterator<T> |
Vec<T> |
||||
property |
- | - | - | T |
- | ||||
Option<T> |
|||||||||
name | - | T |
- | ||||||
properties |
- | - | - | X : FromIterator<(S, T)> where S : FromStr |
HashMap<String, T> |
||||
child |
- | - | - | bool |
- | field / → true /false |
Children.Boolean Child Fields | ||
Option<U> |
- | ||||||||
U (struct) |
- | ||||||||
argument |
T |
||||||||
property |
T |
||||||||
child |
T |
||||||||
children |
- | - | - | Vec<U> (enum) |
- | ||||
name | - | Vec<U> (struct) |
|||||||
enum | - | - | - | Single struct. | Enum | ||||
argument |
|||||||||
arguments |
|||||||||
property |
|||||||||
properties |
|||||||||
child |
|||||||||
children |
DecodeScalar
Named vs Indexed
Any programmes are written sequentially and hence cannot avoid/can exploit their own ordered-ness.
Tuples/tuple structs can naturally be pattern-matched using their elements' appearing order.
On the contrary, the seeming counterpart for enums, the order of arms in pattern-matching is irrespective.