Consider extracting out a zeroize-core crate

[jplatte]

It would be nice if the trait definitions and impls on stdlib types from zeroize could move into a zeroize-core crate. This would allow crates that only need those traits to stay on the syn-free path of a build pipeline, even if something else in the same dependency graph enables zeroize's derive feature.

The same thing is being done for serde, the PR has some impressive numbers: serde-rs/serde#2608 (here it should be a lot easier to do than in serde though, I would assume).

If you agree, I can probably find some time to work on a PR for this.

[tarcieri]

It sounds like you’re describing the zeroize crate in its current form. Custom derive support is an optional dependency and in no way required.

[jplatte]

Custom derive support is an optional dependency and in no way required.

Yes, but if something in the dependency graph enables the zeroize derive feature, anything else in the dependency graph that needs zeroize but not the derives is still stuck waiting for the derive stuff to compile, as it's now a dependency of zeroize. The serde PR I linked explains it in detail, and has some benchmarks as well.

[tarcieri]

I don’t understand. If something else in tree enables custom derive support, it’s definitionally going to pull in the proc macro stack, and no refactoring of zeroize can change that.

zeroize is a very simple crate whereas serde is a very complicated one. I don’t understand what you think would go in zeroize-core that isn’t “the entire existing zeroize crate sans a derive fearure”

[tarcieri]

Okay, now I get what’s being proposed: adding a whole additional crate so it can compile in parallel even if the derive feature is enabled.

I don’t think we’re going to do that. I’m sorry if zeroize is slowing down your builds but I don’t think it justifies the added maintenance burden of yet another additional crate and inevitable complaints about “why are there more crates?”