Kai Ren

@JelteF sorry for bringing this up again, but I have more thoughts about it. > This only impacts the `Pointer` formatter. We could try leveraging this fact. Does the following...

@JelteF > If they only have to that for complex expressions (like my `unsafe` + cast to pointer), but not for simple expressions then I think it's just going to...

@ModProg I'm definitely against skipping in groups, but would like to see PRs for enhancing separate derives or adding new ones.

@50U10FCA7 I guess you've meant `#[mul(forward)]`.

@MegaBluejay no, let's postpone refactoring here as a minor priority task.

@MegaBluejay yes, I start thinking that maybe `transparent` is better here than `forward`. Let's postpone it for a little while... I'll write up some design thoughts during the following week....

@ilslv I guess this is not the case anymore on latest `master`, but maybe you could add tests covering that, just to be sure?

@ModProg that code is gross 😄 I would expect rather something like this: ```rust #[derive(derive_more::Debug)] enum Enum { #[cfg(unix)] A = 2, #[cfg(not(unix))] A = 3, } ``` But yes,...

@JelteF > Or does it work if the crate that contains the struct enables syn its "full" feature itself? Yes, that works, of course. However, given that the `derive_more` is...

@JelteF some report on integrating `1.0.0-beta.3` in our codebase. ### Bugs Only 3 bugs were discovered during integration: #287, #288, #289 Everything else worked out very well. Legacy syntax diagnostics...