-
-
Notifications
You must be signed in to change notification settings - Fork 53
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
Request for Enhancement: Project-level Deku settings #217
Comments
Is this possible? I think there is no way to access such file level settings in a procedure macro. |
Any further thoughts on this, @sharksforarms? |
This would be better suited in another library using deku. For example, another proc-macro crate which annotates struct/enum fields with deku attributes |
Could you show me an example of such a crate/project please? |
The following is an example of using deku attributes in another proc-macro library. If that is what you are asking. |
@constfold Any thoughts on #225 (comment) ? Does an attribute named |
Hi @sharksforarms & @wcampbell0x2a, check these out. nom-derive-impl/src/config.rs This will cut my boilerplate noticeably. |
I'm still not sure how I'd like to approach this, if at all. Have you considered writing your own proc-macro to accomplish this? I'll try and give you an example when I have time to create one. |
Thank you. As I had mentioned, I'm a noob at programming, barely capable of using this library. The approach taken by |
Project-level settings that are set within
main.rs
can help reduce boilerplate significantly.Imagine a
#[deku(endian = "little")]
for each & everystruct
orenum
.This will make a very noticable difference in readability when working on projects with hundreds of
struct
s andenum
s.Over time, project-level settings can be used for future enhancements whenever they come up.
As always, thanks for your time & effort to all the contributors of this very neat project.
The text was updated successfully, but these errors were encountered: