Try to remove proc macros?

[mcbegamerxx954]

Problem solved by the enhancement

Way less dependencies by default,
(19 -> 1), smaller build folders, and faster build times (22s to 5s)

Enhancement description

Procedural macros can be pretty ergonomic and dev-friendly, But they still have a cost, maybe removing them is a good idea as It makes the library smaller in dependency footprint, i attempted to do this in my fork, its still incomplete and unpolished but It builds with default features (apart from some tests being commented off due to "duplicate")

[Marcono1234]

Thanks for the suggestion, and for the proof of concept! If I understand it correctly, part of the problem here are also the transitive dependencies like proc-macro2 and syn, right? So the main build time improvements would only happen if all proc macro usage is removed?

Regarding the currently used proc macros:

• strum:
  Only using its Display derive; manually implementing it might be a bit verbose but I guess I could live with that. Maybe that change on its own already improves build time because its strum_macros seems to take more than 1 second to build on my machine.
• duplicate:
  Your changes look quite ok to me (is the new internal NumberTrait for the writer really needed though?). I assume it would also help to move it to dev-dependencies; then users of Struson would not be affected by its build time, but the tests could continue using it.
  Side note: It seems using default-features = false removes the transitive dependency on proc-macro2. But it might make troubleshooting errors more cumbersome, so not sure about that. Moving it to dev-dependencies might be better.
• thiserror:
  For now I think I would like to keep this one. Manually implementing Display, Error (also its source method) and From would be rather verbose.

If you could create two PRs (one for each) for making duplicate a dev dependency, and for removing strum, that would be great!

I can't guarantee though that I won't add back these other other proc macros at some point in the future, in case they really simplify the implementation of Struson.

[mcbegamerxx954]

Thanks for the suggestion, and for the proof of concept! If I understand it correctly, part of the problem here are also the transitive dependencies like proc-macro2 and syn, right? So the main build time improvements would only happen if all proc macro usage is removed?

For syn to stop being in the dependencies, having all proc macro deps removed seems to be the only fix

Regarding the currently used proc macros:

• strum:
  Only using its Display derive; manually implementing it might be a bit verbose but I guess I could live with that. Maybe that change on its own already improves build time because its strum_macros seems to take more than 1 second to build on my machine.
• duplicate:
  Your changes look quite ok to me (is the new internal NumberTrait for the writer really needed though?).

Its not really needed as It was a attempt to achieve what i wanted using traits, can clean that up

I assume it would also help to move it to dev-dependencies; then users of Struson would not be affected by its build time, but the tests could continue using it.

Sounds ok

• thiserror:
  For now I think I would like to keep this one. Manually implementing Display, Error (also its source method) and From would be rather verbose.

Reasonable as i had to do quite a lot of manual writing to get that dependency out, but i think we can get something quite similar to It with a declarative macro

If you could create two PRs (one for each) for making duplicate a dev dependency, and for removing strum, that would be great!

I will try to do separate prs for the dependencies i remove

I can't guarantee though that I won't add back these other other proc macros at some point in the future, in case they really simplify the implementation of Struson.

Thats quite ok, as there are some situations where they can really save time

[Marcono1234]

Are you still interested and have time to make duplicate a dev-dependency? If you need more time, then no hurry.

No problem in case you don't have the time for it. Your feedback was already very useful!
Is it ok for you then if I make the changes, based on the code from your fork? (assuming I don't run into any issues)