4 ms·

I don't disagree with this... but is there anything wrong with recommending `thiserror` by default, especially for less experienced Rustaceans? It's fairly sane

I don't disagree with this... but is there anything wrong with recommending `thiserror` by default, especially for less experienced Rustaceans? It's fairly sane, encourages "good" error design. I wish there'd been something like it when I started. And moving forwards, you could a) still write out the error type and associated code to replace `thiserror` fairly easily, or b) possibly benefit from any work being done to speed up proc macros in the future. So I feel like recommending it as a default is still the best option?

burntsushi 4y ago
That's a harder question to answer IMO with less clear trade offs. It gets into pedagogical style. I think for me, it depends on what's being done, but I can see how it might be a decent recommendation by default. I think you can afford a sentence about its cost though, so I'd suggest including that. When in doubt, present the trade off.
- bluejekyll 4y ago
  It might be worth doing this on a stable crate, that doesn’t have a lot of dependencies. For me, when there are so many it’s a trade-off. Sure, hand coding it isn’t hard, maybe you can even build a macro_rules that can deal with most of the down the middle cases, but ultimately thiserror makes development faster and simpler. It’s always something that can be optimized away pretty easily later.
  - burntsushi 4y ago
    Yeah I guess I've just never been in a situation where making the definition of error type take ~1 minute vs ~5 minutes (for example) was a difference maker. Firstly because the frequency of defining new error types is so low. And secondly because it often takes me longer to even figure out what the error type should look like. The savings from 'thiserror' is basically just in the noise for me. I would use it if it were in 'std' though. I would also use it in a project that already had a lot of dependencies, since it's likely such a project is probably already bringing in the proc-macro stuff.

burntsushi 4y ago

That's a harder question to answer IMO with less clear trade offs. It gets into pedagogical style. I think for me, it depends on what's being done, but I can see how it might be a decent recommendation by default. I think you can afford a sentence about its cost though, so I'd suggest including that. When in doubt, present the trade off.

bluejekyll 4y ago
It might be worth doing this on a stable crate, that doesn’t have a lot of dependencies. For me, when there are so many it’s a trade-off. Sure, hand coding it isn’t hard, maybe you can even build a macro_rules that can deal with most of the down the middle cases, but ultimately thiserror makes development faster and simpler. It’s always something that can be optimized away pretty easily later.
- burntsushi 4y ago
  Yeah I guess I've just never been in a situation where making the definition of error type take ~1 minute vs ~5 minutes (for example) was a difference maker. Firstly because the frequency of defining new error types is so low. And secondly because it often takes me longer to even figure out what the error type should look like. The savings from 'thiserror' is basically just in the noise for me. I would use it if it were in 'std' though. I would also use it in a project that already had a lot of dependencies, since it's likely such a project is probably already bringing in the proc-macro stuff.