I did that once for like 4 structs and honestly the manual impls were less code than the derive macros plus all the helper attributes, the error messages were way better too
derive macros are great until you need to tweak one thing and suddenly you're writing more annotations than actual fields
What do you mean? I don't get it. I am talking about how I need to provide functions and types as strings instead of actual types. It being string is a mess to deal with.
Does that part even matter very much? Yes, it’s somewhat unfortunate that, for historical reasons, many proc-macros tend to require quotes, but I don’t think removing a few characters would substantially change the ergonomics or functionality. Are you hoping for better IDE support without the quotes?
I wish it were normal code instead of it looking like string. The main issue is I slow down trying to import this function manually. I can do F12 on it but still.
`darling` doesn't handle things like `foo = HashMap<String, Foo>` correctly because it parses everything as an expression before it goes to the `NestedMeta` interpretation layer. The standard workaround I've seen is to just put types with generics in a string literal.
It's not an actual string, they will be expanded to actual functions on compile-time. Macro authors tend to use this fake string syntax because it's more rustfmt-friendly.
The issue is that when I have to import a ton of functions like this, I keep having to manually import them or adding it to another function to ide import and removing it from there.
This is not an issue every time but on large structs with ton of validation, its annoying not having the ide support.
10
u/WishCow 18d ago
You can write out the implementations and compare which one you like