Possible future improvements

[daxpedda]

These are code improvements or features that could be added in the future if demand is there:

• Revive Implement Ord for mem::Discriminant rust-lang/rust#51561, which would get rid of the nightly crate feature and remove parts of the safe crate feature implementation.
• Improve safe PartialOrd and Ord codegen, done in Improve code generation of Ord and PartialOrd #38.
• Implement #[derive_where(Clone; T = u8)], which will generate impl Clone for Test<u8>.
• Crate feature to disable warnings, currently errors that don't prevent derive-where from functioning correctly but point to invalid use-cases (use std derive) instead or bad code quality (empty bracers). Currently Rust doesn't have a compile_warn.
• Remove quote and build any Rust code purely with syn structures instead.
• Improve generated code, mainly remove match and access fields directly when not dealing with an enum. This is mainly modeled after std's derive, which was probably done to make it easy to implement as it makes code generation between enums and structs very similar, but after many refactors, there is no real advantage anymore.
• Use once-cell or something similar to cache patterns and Idents, some implementation don't need them, but we don't want to generate them ad-hoc as they do some allocations. The main concern here is adding another dependency.
• Use arrayvec or something similar to store traits, reducing overall allocations. We know what the maximum amount of possible traits are, no need to do any allocations. To reduce dependencies we could make our own.
• Use smallvec or something similar to store fields and such, we don't expect structs to have an unlimited amount of fields. Again, another dependency.

[ModProg]

One thing I would like to do at some point, maybe as a feature would be some way to get rid of the #[derive(DeriveWhere)] even without rust-lang/rust#65823.

Maybe that would be doable as a normal macro even, that just generates the more verbose syntax.

[ModProg]

• We use both attr.rs and test/mod.rs I'd lean toward making them all mod.rs.

[daxpedda]

We could use this lint:
https://rust-lang.github.io/rust-clippy/master/index.html#self_named_module_files

[daxpedda]

rust-lang/rust#106418 is in it's FCP with a disposition to merge!
Still have to figure out what to do about the MSRV then.

[ModProg]

Oh, that would be big. We could have a feature that enables the current unsafe work around and therefor keeps the msrv down?

[daxpedda]

I would probably do it the other way around, add a crate feature that enables the new behavior but raises the MSRV.
Alternatively we could use rustversion.

In any case, we could remove the nightly feature with that.