bowbahdoe / mccue.dev-comments

0 stars 0 forks source link

pages/8-1-24-i-cant-run-my-rust-game #22

Open utterances-bot opened 3 months ago

utterances-bot commented 3 months ago

I Can't Run My Rust Game Either

https://mccue.dev/pages/8-1-24-i-cant-run-my-rust-game

tirr-c commented 3 months ago

For the point 2: The problem is that BOOL abstraction of objc is error-prone, and winit 0.19.5 actually misused that. In objc we have this:

/// The Objective-C `BOOL` type.
///
/// To convert an Objective-C `BOOL` into a Rust `bool`, compare it with `NO`.
#[cfg(not(target_arch = "aarch64"))]
pub type BOOL = ::std::os::raw::c_schar;
/// The equivalent of true for Objective-C's `BOOL` type.
#[cfg(not(target_arch = "aarch64"))]
pub const YES: BOOL = 1;
/// The equivalent of false for Objective-C's `BOOL` type.
#[cfg(not(target_arch = "aarch64"))]
pub const NO: BOOL = 0;

#[cfg(target_arch = "aarch64")]
pub type BOOL = bool;
#[cfg(target_arch = "aarch64")]
pub const YES: BOOL = true;
#[cfg(target_arch = "aarch64")]
pub const NO: BOOL = false;

So they work differently whether it's compiled for aarch64 (Apple Silicon Macs) or not.

Authors of objc intended to use YES and NO consts to convert to and from boolean values, but nothing in the type system actually enforces it. I think it should be a #[repr(transparent)] newtype struct with some type conversion methods.

hinst commented 3 months ago

Cross platformed Rust code no longer compiles after 4 years 🤔💭🚿