Improved panic safety.

[gtsiam]

The issue with HidApi::new_without_enumerate() is that it makes both it and HidApi::new() potentially panic, with no way out in library contexts.

Instead, on platforms that need it, the same effect can be achieved by calling the newly added HidApi::disable_device_discovery() before any HidApi contexts are created.

[gtsiam]

This PR is approaching 1 Year old! Happy birthday! But also it's time to kill it cause I don't like seeing it in my backlog.

@ruabmbua Would you like me to get this into a clean state so we can merge it and be done with it Y/N?

[ruabmbua]

Honestly I think my response got lost in the ether, I remember I wrote something ...

Glancing over it again, you made a couple of modifications to build.rs, they do not actually have anything to do with what is described in the MR?

About the API change, it feels like the new API is a bit less "rust idiomatic", as it has more global state exposed in the API surface compared to before. Can we maybe resolve the panic issue while keeping the API more like before?

Also, do you have any concrete examples where its preferred to not panic? In my opinion if a problem can`t be handled, its totally ok to panic in rust.

Is it maybe that you consume hidapi in another library, and you do not want to have any panics reaching the user of your library?

[gtsiam]

Okay, since I actually got a response, I went ahead and fixed it up so we can talk about something concrete:

The main point of this PR:

• Introduce HidApi::disable_device_discovery().: The library works the same way as it did before. The new function makes what was implicitly global state before, explicit. That's just the nature of working with C libraries.
• Deprecate HidApi::new_without_enumerate().: Adds the deprecation notice. I don't know the next version, so I can't add a since = "..." here. The intention is to discourage use of it while favoring the explicit approach.

Housekeeping:

• Remove unnecessary function boxes from build.rs: What it says on the tin. Clippy was complaining about type complexity (which is a bit of a bogus lint, but I digress). But in this case the types were, in fact, unnecessarily complex.
• Fix warning in example: This time it's cargo check complaining. This takes care of that.

I'm just not gonna open one more PR that will never get merged and have to keep track off. It's the part I hate about the PR system, but I digress. Originally I had also split build.rs into a more manageable pieces rather than the current monolith - but I can't be bothered to do that again.

---

About the API change, it feels like the new API is a bit less "rust idiomatic", as it has more global state exposed in the API surface compared to before. Can we maybe resolve the panic issue while keeping the API more like before?

No. Not as long as you set global state in a C library in the backend. The global state is there in our dependencies and we can't pretend it's not. Maybe if you dive into libusb, figure out how it does device discovery and try to replicate it on the rust side? But I'm not personally interested in doing that work.

Also, do you have any concrete examples where its preferred to not panic? In my opinion if a problem can`t be handled, its totally ok to panic in rust.

I don't have a problem with panicking. I have a problem with panicking, effectively at random, in what should be a mostly infallible function for no good reason.

Imagine you're integrating a few libraries. Some use hidapi. Some libusb directly. Crappy device drivers and such. Now put yourself in the driver author's position:

impl MyDriver {
  fn new() -> Self {
    // Do I use new() or new_without_enumerate()? I don't know.
    // If another library has already been initialized before me,
    // one will panic, and one won't. Which? I don't know, it's a coin's toss.
    //
    // Or rely on the integrator to match the version of new that is called on every single library.
    // ...
    // That sounds like fun!
    let hidapi = HidApi::new();

    // ...
  }
}

[ruabmbua]

Thanks for revisiting the MR, I appreciate the work!