Whats the reason for introducing the methods? I would prefer keeping it opaque for the same reasons discussed in #3795.

@daxpedda we need a way to build those types when backends will be split.

I can make those functions private for now, but they'll be public eventually...

@daxpedda we need a way to build those types when backends will be split.

No, we can have Winit introduce its own DeviceId type that wraps this one to keep it opaque.
This problem was discussed in the last two meetings.

Generally speaking I'm always leaning towards making compromises internally rather then on the public API, which is to me the most important part of the whole project.

I'm in favor of keeping them private as long as the types are still in the winit crate.

I mean, if the core types are in winit-core including DeviceId, I'm not sure how you'd create one without e.g. Box or something like that.

Like with a layout like

// winit-core

pub trait DeviceEventHandler: ApplicationHandler {
    fn device_event(&mut self, device_id: Option<DeviceId>, event: Event); 
}

// winit-wayland
{
     // Should be `DeviceId`, but no way to build?
     state.device_event(device_id???, event)
}

It's true that if you re-export everything possible inside the winit and wrap everything, you can probably avoid certain things, but however you can not create traits with types like that, or at least there still should be a type that can be build from e.g. u64.

Unless you just do dyn, but dyn for Id doesn't make any sense.

I've removed public API for now, so should be less concerning.