Hi,

I'd welcome any thoughts, pointers and suggestions on MusicalNinjaDad/try_v2: Provides a derive macro for Try (try_trait_v2).

In particular:

• I've ended up with a lot more code than I expected, even after regular pruning. To my eye most of the verbosity is ensuring useful compiler errors, but still if anyone spots duplication or anything that could be simpler ...
• I've structured it the way I would usually (EAFP): parse & bail-as-you-go on unsatisfied invariants. I generally dislike LBYL (validate invariants, parse validated input) for various reasons. I'm assuming good-practice with proc-macros is also to prioritise the happy-path, as most of the time the code will compile, and I've not noticed any performance niggles when typing with rust-analyzer running and constantly compiling incomplete code.
• I am still stuck with two instances of unreachable! and a few expect - where I know the compiler will already error before getting here but would need very convoluted code to formally prove this to the compiler.
• Does anyone have any better examples for the docs? I've put in a simplified version of the use case that led to me creating this.
• Is it considered bad form to create something like this making unstable features easier for the wider community to access, while they are still in active development?

(A note on AI: this is all my own hand-written code. I've used sourcery and copilot for reviews but always used my own brain to consider any suggestions and then hand-implemented the code following my own stylistic preferences)

Thanks

1 post - 1 participant

Read full topic