Allow #[from] or #[from(ignore)] in regular structs

[Xion]

#[derive(From)]
struct Example {
    main_field: u32,
    some_extra: bool,
}

Currently, the code above produces impl From<(u32, bool)>. There is no way, AFAIK, to make derive_more create an impl From<u32> instead, with some_extra being set to Default::default().

It would make sense to permit this by using either #[from] or #[from(ignore)]:

#[derive(From)]
struct Example {
    #[from]
    main_field: u32,
    some_extra: bool,
}

#[derive(From)]
struct Example {
    main_field: u32,
    #[from(ignore)]
    some_extra: bool,
}

For fields that were ignored this way, the From impl would use their default values when performing the conversion.

The requirement for those fields to implement Default doesn't seem particularly onerous but it could nevertheless be lifted as well, similarly to how serde does it:

fn true_() -> bool { true }

#[derive(From)]
struct Item {
    data: String,
    #[from(default = "true_")]
    alive: bool,

[JelteF]

I agree that both being able to ignore and being able to set defaults would be quite useful. PRs welcome.

[lasantosr]

@JelteF maybe you can include a reference to model-mapper in the From/Into/TryFrom/TryInto section of the readme like you have with derive-new.

It's a crate to derive those traits with more advanced use cases.

[balsoft]

This is fixed by #500; the attributes there are a bit more flexible, allowing you to set the fields to be derived via #[from], e.g. the first example should work as-is:

#[derive(From)]
struct Example {
    #[from]
    main_field: u32,
    some_extra: bool,
}

Or setting default values with #[from(<default value>)], e.g. the third example should work with a minimal change:

#[derive(From)]
struct Item {
    data: String,
    #[from(true)]
    alive: bool,
}