Concerns about rolling your own derive macro framework

[coolreader18]

I don't know how much my opinion counts here, obviously feel free to discard as it's your project, but to me the zero-dependency-ness of virtue isn't as valuable to me as correctness of the parsing. I'm looking into implementing #511 and reading the source code of virtue because of that and even just glancing I can see some edge cases where parsing would fail (e.g. where Foo: Bar<{ CONST_GENERIC }> would interpret the { } group as the function body. also the case I commented in that issue). It seems like virtue focuses on the happy path of struct Ident { field: Type } but rust's grammar is much more complex than that and is always evolving; syn is well supported/maintained, well-tested in catching edge cases, and keeps up to date with the grammar. virtue is also not very flexible for generation; in order to implement #511 I'm pretty sure I'd have to make some change to virtue which makes contributing harder.

(Oh, also, for syn the cost is lessened if more than one derive macro is in the dependency tree b/c it's so ubiquitous, that's not the case for virtue, it'll always add compile time if I use bincode_derive)

[ZoeyR]

The reason we switched to virtue instead of using syn is because bincode has a hard MSRV requirement. Bumping MSRV constitutes a major version bump for bincode. This is bad because syn does not have the same policy. So if syn were to up their MSRV beyond the bincode 2 MSRV we would have to stop using it anyways. I know that syn is battle tested but it unfortunately does not suit bincodes needs.