Why is the proc macro package not a part of the rust standard library but rather a third party package ? Does that not hold the risk of sudden change or disappearance in the event of production use.
But it is part of it? proc_macro - Rust
1 Like
It's a separate crate from std but still first party. It comes with your rust install. The crates you get are std, alloc, core, test, and proc_macro.
proc_macro2 is a third party crate, but it should be noted that there isn't much distinction between third party and first party in the Rust ecosystem.
3 Likes
While it is possible to yank crates on crates.io, yanked crates remain usable. Cargo will only refuse to create a new lockfile containing yanked crates, but it will keep using an existing lockfile which contains yanked crates. Crates can only be removed from crates.io through manual action by someone on the infra team with appropriate permission. This is only done in exceptional circumstances like malware or DMCA requests which would apply to the rust standard library too.
1 Like
According to the book you do need to use the 3rd party crates syn and quote use the TokenStream. I see where OP is coming from. It seems strange to me to outsource to a 3rd party library to take advantage of a bona fide feature of the language.
Maybe the idea is that you can actually parse the TokenStream without these tools but it's just cumbersome and so book just has you use David Tolnay's library? Just thinking out loud I suppose.
Exactly. It's just very convenient, but not strictly necessary. They are one of the most downloaded crates ever, so if something's going to happen, you'll have bigger problems.
1 Like
Putting proc-macro support libraries on crates.io rather than in the standard library means that multiple versions of them can exist, and they can be maintained and improved without having to be mostly frozen forever except for additions, like the Rust standard library is. The job of the standard library is not to provide everything you might want to write Rust programs, but to provide the fundamental things for interop between separately written Rust libraries, and almost never change in a way that would break those libraries. For macros, the interop layer is "token streams only", so that's what you get.
This isn't without downsides — for example, syn might turn out to parse Rust code differently than the compiler version in use does — but it's better than being stuck with a complex and also unfixably broken or compromised design included in the standard library, as would likely happen if syn-like functionality were included.
All that said, proc-macro2 certainly is more of an “exists due to technical limitations” library — there's no great advantage to it being independent, because proc-macro2 mirrors proc-macro and proc-macro is subject to standard library versioning rules.
4 Likes
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.