Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible future improvements #25

Open
1 of 9 tasks
daxpedda opened this issue Dec 7, 2021 · 6 comments
Open
1 of 9 tasks

Possible future improvements #25

daxpedda opened this issue Dec 7, 2021 · 6 comments
Labels
enhancement New feature or request

Comments

@daxpedda
Copy link
Collaborator

daxpedda commented Dec 7, 2021

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.
@daxpedda daxpedda added the enhancement New feature or request label Dec 8, 2021
@ModProg

This comment was marked as outdated.

@ModProg
Copy link
Owner

ModProg commented Dec 24, 2022

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

@daxpedda
Copy link
Collaborator Author

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

@daxpedda
Copy link
Collaborator Author

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
Copy link
Owner

ModProg commented Aug 24, 2023

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

@daxpedda
Copy link
Collaborator Author

daxpedda commented Aug 24, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants