Repository navigation
Merge RawWindowHandle and WindowHandle<'_>? #178
Description
Activity
Another option to simplify things would perhaps be to get rid of the platform-specific wrappers? Something like:
#[non_exhaustive] enum RawWindowHandle { #[non_exhaustive] AppKit { ns_view: NonNull<c_void>, }, #[non_exhaustive] UIKit { ui_view: NonNull<c_void>, }, #[non_exhaustive] AndroidNDK { a_native_window: NonNull<c_void>, }, // ... etc. } impl RawWindowHandle { pub fn new_appkit(ns_view: NonNull<c_void>) -> Self { Self::AppKit { ns_view } } pub fn new_uikit(ui_view: NonNull<c_void>) -> Self { ... } // ... etc. } // Keep this impl WindowHandle<'_> { fn borrow_raw(...) }
This has the downside that fields have to be public, because enums have no visibility rules. But if our fields are public anyhow, we might as well IMO.
Reacted by Kirill ChibisovI'm fine with getting rid of raw window handles entirely, assuming we can't come up with a better use case. As an added bonus, it lets us have more granular safety rules for each window handle. For example, we can make it safe to construct an XCB window handle, but not a Win32 window handle.
One argument for raw handles is it lets us have a raw pointer equivalent for window handles.
Reacted by Mads MarquartTwo points from today's meeting:
- It's good to have a
RawWindowHandlethat represents plain old data, compared to aBorrowedWindowHandle<'static>that represents a valid live window handle. - We should move forwards with getting rid of the subtypes.
- It's good to have a
- linked a pull request that will close this issueMerge platform-specific handles into `Raw*Handle` #214
on Mar 14, 2026
I don't recall the reasoning for keeping
RawWindowHandlearound, is there ever a case where it's useful? And wouldn'tWindowHandle<'static>be able to serve that same purpose?I propose we change our API to merge these, so that it's instead something like:
This means that instead of a three-step process for making safe handles (create raw platform handle + wrap in
RawWindowHandle+ callWindowHandle::borrow_raw), it's now only two steps (create raw platform handle with lifetime + wrap it inWindowHandle).One reason to not do this would be to mirror the
std::os::fdAPI (RawFdvsBorrowedFd<'_>), but we already can't do that, because we can't provide a mirror ofOwnedFd.