not-fl3
Make derive macros use fully-qualified paths
This PR makes the macros in this crate use fully qualified paths, which prevents assumptions about what's in the user's scope. For example, this makes it possible to use #[derive(nanoserde::SerJson)] without first writing use nanoserde::SerJson;, which allows this crate to be used in other macros (my requirement).
I think I've caught everything, but there are around a thousand lines of (very impressive) manual macros, so it's entirely possible that I've missed a few things!
By the way, thanks for this crate, it's extremely useful!
@not-fl3 when do you think this is likely to be released to crates.io? I don't mean to pressure you, I'm just wondering how I should manage the releases of a project I'd like to integrate this into.
If I understand correctly, the tradeoff here:
With this PR we disallow using nanoserde with crate rename (like this: notserde = {package = "nanoserde"} use notserde::SerBin;), but allow using #[nanoserde::SerBin]?
Honestly, I do not remember(and can't really find out on the internet fast enough) if this is the only implication here, so I just do not know enough to make a decision on merging this right now :(
Hmm true, I hadn't considered that. As far as I know though, this use of fully qualified paths is just about ubiquitous in other macro crates, so this behavior would be more expected by users than being forced to import things (which I've found very restrictive in using this in a macro of my own that automatically derives SerJson and DeJson --- the user has to either import things that they can't see being used, or they get double-import errors if they want to derive those on other things in their code).
@not-fl3 by the way, the user renaming of the crate wouldn't work even without this PR, since there were multiple existing (and necessary) references to nanoserde in the code.
Honestly, I am not convinced std:: paths make anything better. Especially for types that are actually from core::, not std
And for the nanoserde:: paths, I just do not have an opinion strong enough to either merge it nor not, but the std:: thing gives me a reason to just postpone the decision :)
I've removed the absolute paths for Option, Into, From, and AsRef. I haven't done so for Result because a lot of people have custom Result types in scope. Let me know if there's anything else you'd like me to change.