Attribute for skipping field of struct in Debug derives?

[alexreg]

Could we have something like this?

#[derive(Debug)]
struct Foo {
    pub a: A,
    pub b: B,
    #[skip_derive]
    pub c: C, // especially useful if C : !Debug
}

This could also feasibly be applied to other auto-derivations, of course (not just Debug).

[durka]

At minimum we could certainly do it in a library with Macros 1.1 (then it would need a different name like #[derive(DebugEx)]).

[alexreg]

Yeah, that would be a step forward at least. Would be nice to have it work for the built-in Debug though, I think.

[mcarton]

I started such a library a few days ago that does that: https://github.com/mcarton/rust-derivative.
It's not finished, not really documented, not published on crates.io, but the POC is there 😅

[alexreg]

Cool, thanks for sharing that. Is Macros 1.1 already fully implemented in nightly then? I may give it a go shortly.

On 7 Oct 2016, at 15:39, Martin Carton notifications@github.com wrote:

I started such a library a few days ago that does that: https://github.com/mcarton/rust-derivative https://github.com/mcarton/rust-derivative.
It's not finished, not really documented, not published on crates.io, but the POC is there 😅

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #37009 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AAEF3C1_mt5g26LCXeOHH8_2Xl8oPozmks5qxlmXgaJpZM4KQgfg.

[alexreg]

I'm wondering with all the recent Macro 2.0 developments whether the derive attribute macro might become a crate of its own in the future, such that it could be enhanced without changes to the actual compiler. A feature like this would then be much easier to get implemented, I suspect. Thoughts, @jseyfried @Manishearth?

[sfackler]

Custom derives can already be implemented outside of the compiler.

[alexreg]

@sfackler You misunderstand. I mean the workings of the derive attribute macro itself.

[sfackler]

How would pulling libsyntax_ext::deriving into a different crate make this feature easier to implement? Difficulty of implementation is not the limiting factor here in any case.

[Manishearth]

It actually is. The stage1 compiler cannot depend on proc macros IIRC. I suppose you could still make it work with some shimming of libproc_macro and including it directly in libsyntax.

…

On Feb 3, 2018 9:28 AM, "Steven Fackler" ***@***.***> wrote: How would pulling libsyntax_ext::deriving into a different crate make this feature easier to implement? Difficulty of implementation is not the limiting factor here in any case. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#37009 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABivSM9JAEoWXYntq2eAop_hqxcPNJBLks5tQ9llgaJpZM4KQgfg> .

[sfackler]

But that would mean that deriving can't be pulled out to a proc macro, not that pulling it out to a proc macro would make it easier to add extra control attributes, right?

[alexreg]

I was thinking more of maintainability and neat, elegant separation of concerns. Not sure on the details of what @Manishearth just said, but that could be an interesting point.