Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make DeviceId/WindowId::dummy() safe #3784

Merged
merged 1 commit into from
Jul 14, 2024

Conversation

daxpedda
Copy link
Member

I'm sure this had some historical context, but none of these IDs are passed into anything anymore.
I included this in the Winit 0.30.4 milestone because this isn't a breaking change.

Let me know if this is somehow a bad idea.

@daxpedda daxpedda added the S - enhancement Wouldn't this be the coolest? label Jul 10, 2024
@daxpedda daxpedda added this to the Version 0.30.4 milestone Jul 10, 2024
@notgull
Copy link
Member

notgull commented Jul 11, 2024

Looks like @madsmtm asked this a while back here. The verdict is that it isn't a breaking change.

For me, the question is "is there any way in which calling DeviceId::dummy() can put the program in an invalid state"? As far as I know, there isn't. In fact I think it's guaranteed for most backends that dummy does not correspond to a real window.

Copy link
Member

@madsmtm madsmtm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect it was previously unsafe because the WindowId is storing a HWND on Windows, and may have been passing that to window functions in the past? Or is this still done somewhere? If so, then we might have to change that first.

In any case, this is approved for the AppKit/UIKit platforms.

Looks like @madsmtm asked this a while back

And got it put into the documentation 💪.

@madsmtm madsmtm mentioned this pull request Jul 11, 2024
Copy link
Member

@kchibisov kchibisov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be fine given that APIs relying on WindowId are unsafe, but it doesn't make a dummy constructor unsafe because it can not ensure validity anyway, so the whole object is safe to write but unsafe to use since it doesn't retain anything.

So, if the API relies on Device/Window id, because they represent something it should be unsafe on its own, but not the constructor to build such object, because you can not do anything bad when building since it's pod.

@@ -65,6 +65,7 @@ changelog entry.
`ApplicationHandler::resumed/suspended()` are now only emitted by iOS and Web
and now signify actually resuming/suspending the application.
- Rename `platform::web::*ExtWebSys` to `*ExtWeb`.
- `DeviceId::dummy()` and `WindowId::dummy()` are now not `unsafe`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably this is a bit better than double negation.

Suggested change
- `DeviceId::dummy()` and `WindowId::dummy()` are now not `unsafe`.
- Mark `DeviceId::dummy()` and `WindowId::dummy()` as safe.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I intentionally avoided the word "safe" because its not 100% clear that we are talking about removing Rust unsafe.

Suggested change
- `DeviceId::dummy()` and `WindowId::dummy()` are now not `unsafe`.
- `DeviceId::dummy()` and `WindowId::dummy()` are no longer marked `unsafe`.

Doesn't remove the double negation, but I think using the verb "mark" makes it much easier to understand.

@daxpedda daxpedda merged commit 5b8f5cb into rust-windowing:master Jul 14, 2024
53 checks passed
kchibisov pushed a commit that referenced this pull request Jul 16, 2024
kchibisov pushed a commit that referenced this pull request Jul 16, 2024
kchibisov pushed a commit that referenced this pull request Jul 16, 2024
kchibisov pushed a commit that referenced this pull request Jul 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S - enhancement Wouldn't this be the coolest?
Development

Successfully merging this pull request may close these issues.

4 participants