4 ms·

Why is it an extensibility hazard (assuming you mark the `pub enum Error` as non-exhaustive)? I mean I don't see the difference between having the non-exhausti

by IshKebab 11mo ago

Why is it an extensibility hazard (assuming you mark the `pub enum Error` as non-exhaustive)? I mean I don't see the difference between having the non-exhaustive enum at the top level vs in a subordinate 'kind'.

epage 11mo ago
Take the example at https://docs.rs/thiserror/latest/thiserror/ https://docs.rs/thiserror/latest/thiserror/ - Struct variant fields are public, limiting how you evolve the fields and types - Struct variants need non_exhaustive - It shows using `from` on an error. What happens if you want to include more context? Or change your impl which can change the source error type None of this is syntactically unique to errors. This becomes people's first thought of what to do and libraries like thiserror make it easy and showcase it in their docs.
- the8472 11mo ago
  Having private variants and fields would be useful, yeah. Std cheats a bit with its ErrorKind::Uncategorized unstable+hidden variant to have something unmatchable.
  - IshKebab 10mo ago
    Probably because non-exhaustive enums didn't exist when it was written?
- IshKebab 10mo ago
  > Struct variant fields are public, limiting how you evolve the fields and types But the whole point of thiserror style errors is to make the errors part of your public API. This is no different to having a normal struct (not error related) as part of your public API is it? > Struct variants need non_exhaustive Can't you just add that tag? I dunno, I've never actually used thiserror. Your third point makes sense though.
  - epage 10mo ago
    > > Struct variant fields are public, limiting how you evolve the fields and types > But the whole point of thiserror style errors is to make the errors part of your public API. This is no different to having a normal struct (not error related) as part of your public API is it? Likely you should use private fields with public accessors so you can evolve it.

epage 11mo ago

Take the example at https://docs.rs/thiserror/latest/thiserror/ https://docs.rs/thiserror/latest/thiserror/ - Struct variant fields are public, limiting how you evolve the fields and types - Struct variants need non_exhaustive - It shows using `from` on an error. What happens if you want to include more context? Or change your impl which can change the source error type None of this is syntactically unique to errors. This becomes people's first thought of what to do and libraries like thiserror make it easy and showcase it in their docs.

the8472 11mo ago
Having private variants and fields would be useful, yeah. Std cheats a bit with its ErrorKind::Uncategorized unstable+hidden variant to have something unmatchable.
- IshKebab 10mo ago
  Probably because non-exhaustive enums didn't exist when it was written?
IshKebab 10mo ago
> Struct variant fields are public, limiting how you evolve the fields and types But the whole point of thiserror style errors is to make the errors part of your public API. This is no different to having a normal struct (not error related) as part of your public API is it? > Struct variants need non_exhaustive Can't you just add that tag? I dunno, I've never actually used thiserror. Your third point makes sense though.
- epage 10mo ago
  > > Struct variant fields are public, limiting how you evolve the fields and types > But the whole point of thiserror style errors is to make the errors part of your public API. This is no different to having a normal struct (not error related) as part of your public API is it? Likely you should use private fields with public accessors so you can evolve it.