Update documentation to capture #161

CHANGELOG.md

@@ -5,7 +5,9 @@
 - **BREAKING CHANGE:** Remove many trait impls from `util::Flag`. 
   This type had a number of deref and operator impls that made it usable as sort-of-a-boolean.
   Real-world usage showed this type is more useful if it's able to carry a span for good errors,
-  and that most of those impls were unnecessary.
+  and that most of those impls were unnecessary. [#179](https://github.com/TedDriggs/darling/pull/179)
+- Remove need for `#[darling(default)]` on `Option<T>` and `Flag` fields [#161](https://github.com/TedDriggs/darling/issues/161)
+- Improve validation of enum shapes [#178](https://github.com/TedDriggs/darling/pull/178)
 
 ## v0.13.4 (April 6, 2022)
 

README.md

@@ -104,7 +104,8 @@ fn do_stuff() {
 # Features
 Darling's features are built to work well for real-world projects.
 
-* **Defaults**: Supports struct- and field-level defaults, using the same path syntax as `serde`.
+* **Defaults**: Supports struct- and field-level defaults, using the same path syntax as `serde`. 
+  Additionally, `Option<T>` and `darling::util::Flag` fields are innately optional; you don't need to declare `#[darling(default)]` for those.
 * **Field Renaming**: Fields can have different names in usage vs. the backing code.
 * **Auto-populated fields**: Structs deriving `FromDeriveInput` and `FromField` can declare properties named `ident`, `vis`, `ty`, `attrs`, and `generics` to automatically get copies of the matching values from the input AST. `FromDeriveInput` additionally exposes `data` to get access to the body of the deriving type, and `FromVariant` exposes `fields`.
 * **Mapping function**: Use `#[darling(map="path")]` or `#[darling(and_then="path")]` to specify a function that runs on the result of parsing a meta-item field. This can change the return type, which enables you to parse to an intermediate form and convert that to the type you need in your struct.

examples/consume_fields.rs

@@ -137,7 +137,8 @@ struct MyFieldReceiver {
     /// We declare this as an `Option` so that during tokenization we can write
     /// `field.volume.unwrap_or(derive_input.volume)` to facilitate field-level
     /// overrides of struct-level settings.
-    #[darling(default)]
+    ///
+    /// Because this field is an `Option`, we don't need to include `#[darling(default)]`
     volume: Option<Volume>,
 }
 

examples/shorthand_or_long_field.rs

@@ -19,7 +19,7 @@ struct MyDeriveInput {
     /// explicit that they're expecting the inference behavior to avoid cluttering some hypothetical
     /// database. Therefore this field is required, but can take word form or key-value form.
     ///
-    /// To make this field optional, we could add `#[darling(default)]`, and we could additionally
+    /// To make this field optional, we could add `#[darling(default)]`, or we could
     /// wrap it in `Option` if the presence or absence of the word makes a difference.
     table: Override<Table>,
 }
@@ -39,7 +39,6 @@ impl MyDeriveInput {
 #[derive(Debug, Clone, FromMeta)]
 struct Table {
     name: String,
-    #[darling(default)]
     value: Option<Path>,
 }
 

tests/from_generics.rs

@@ -20,7 +20,6 @@ struct MyTypeParam {
     pub ident: syn::Ident,
     #[darling(default)]
     pub foo: bool,
-    #[darling(default)]
     pub bar: Option<String>,
 }