Breaking changes OneIoError is now #[non_exhaustive]; match expressions without a wildcard _ arm will fail to compile OneIoBuilder::header() now accepts typed HeaderName/HeaderValue (infallible) i...

Press ← or → to navigate between chapters

I'd personally write getters, but if you prefer public fields, I don't see why you shouldn't make them public (maybe adding a `#[non_exhaustive]` to the type).

I don’t think there are any really rigorous principles to be had here, but more important principles than not relying on panic behavior are that: * types should have only valid values, and * the return value of a function should be truthful. So, if a `DecryptError` previously represented _only_ “the cyphertext is not authentic”, how does it now also represent “the length is invalid”? If `DecryptError` was (or contained) a `non_exhaustive` `enum`, then there is an obvious possibility of adding a variant to it. But if it is not, then `decrypt` is now returning false information. In general, you should _consciously choose_ whether the set of errors returned by a function is extensible. If it is not, then you must not return errors for new cases unless the new cases fall into the existing description of the error, because the caller might be handling the error with an assumption about what it means. If it is extensible, then turning a panic into an error is IMO usually reasonable, but I would want to be more careful with the original documentation and write that it “ _May_ panic if…”. Even more broadly: when you are doing a “1.0” release, or any one where you care about not having breaking changes in your near future, you should review your API surface — both types and documentation — for over-promising the details of things that you might want to tweak later, and remove such promises.

aargh, sorry, I should have searched the forums better before posting

No problem. I happened to remember it being asked.

I'm reading the docs at rfcs/text/2008-non-exhaustive.md at master · rust-lang/rfcs · GitHub but I have a situation where I want to do the opposite to what the feature is trying to do. I understand that when applied to an `enum` the library author who uses `non_exhaustive` is trying to make sure that (a subset of) future breaking changes are handled but I actually want to fail to compile if my dependencies add a new entry into the enum. Instead of having a `_ => todo!()` (because I can't actually implement a default fallback path) I'd rather get a compile error, thus undoing the `non_exhaustive` attribute. As a solid example, I'm currently writing a function with this signature e: WaiterError<O, E>, ) -> Result<WaiterError<String, Infallible>, SdkError<E, HttpResponse>> ``` which is taking an AWS SDK https://docs.rs/aws-smithy-runtime-api/latest/aws_smithy_runtime_api/client/waiters/error/enum.WaiterError.html and stripping it of its generic parameters. To do this I have to pattern match on the `WaiterError` but it is marked `#[non_exhaustive]`. I definitely want to get a compile failure if another entry is added, instead of hitting whatever random code I could put in there as a `_ => ` block.

user16251: > Why is this? The RFC that added that restriction explains the motivation. user16251: > Should structs that mix public and private fields be avoided? I imagine the non-availability of struct literal syntax is almost never the deciding factor on whether a field should be private or a struct be `non_exhaustive`. Usually that's about preserving invariants and library flexibility.