Deprecate and remove impl From<NonZeroU32> for Error.

[briansmith]

The From<NonZeroU32> for Error implementation doesn't do any checking of its inputs; for example, it doesn't verify that an "internal" error code isn't being used, nor does it verify that any internal error code is actually a valid/known one.

I propose:

• Replace all internal uses of it; See Enforce OS errors are in the allowed range. #441 for some progress here.
• Add pub const fn Error::new_custom(value: u16) -> Error
• Add pub const fn Error::new_os(u32) -> Error with range checking, as done in Enforce OS errors are in the allowed range. #441, though Enforce OS errors are in the allowed range. #441 doesn't make it pub.
• Mark the impl From<NonZeroU32> for Error as #[deprecated] now.
• In a future SemVer-breaking release, remove the implementation.

This way, internal errors will eventually only be able to be constructed from within the crate.

[josephlr]

I like this idea, having something like:

impl Error {
  pub const fn from_os_error(i32) -> Self;
  pub const fn raw_os_error(self) -> Option<i32>

  pub const fn new_custom(u16) -> Self;
  const fn new_internal(u16) -> Self;
}

seems reasonable to me. We may want to use i32 consistently for OS errors as that's what libstd uses (and it's the return type of errno).

EDIT: Should we also remove the Error::code method?

[dhardy]

EDIT: Should we also remove the Error::code method?

@newpavlov decided to do this in #507, but I don't see a replacement. Should we add the following?

pub const fn custom_code(self) -> Option<u16>;

[newpavlov]

@dhardy
What is the use-case for it I believe it should be sufficient to match Error with the associated constants. The absence of such method allows us to make the custom codes "private" and change them if necessary.

[dhardy]

If a custom source is used and it is wished to handle these errors somehow later — but no, I don't have any specific use case in mind.

The absence of such method allows us to make the custom codes "private" and change them if necessary.

Nothing changes here since we already have pub const fn new_custom and custom_code can use internal arithmetic.

[newpavlov]

I meant that we can change for example UNSUPPORTED from new_internal(0) to new_internal(42).

Addition of such method will be a backwards compatible change, so we can do it later in the case if someone requests such method.

[dhardy]

Changing CUSTOM_START would be a non-breaking change either way (ignoring the Debug output).

Sure, this can be added later if needed.