Winit: Support `run_return` on macos

[chrisduerr]

Currently the macOS target platform does not support the run_return method of the desktop event loop extension. Since I haven't been able to find the time to look into this myself, I've decided to create this issue to track it.

This is currently the biggest thing still missing from the event loop 2 rework as far as Alacritty is concerned. The run_return method is mainly required for its lifetime, allowing to run it without having a 'static constraint for the event handler. So I don't think just adding a 'static bound to the run_return trait and calling the run method is an option.

[XVilka]

Are there any updates on this?

[Osspial]

@XVilka Not that I'm aware of. From what I've seen skimming the macOS code this shouldn't be too hard to implement, but I'm not familiar with the semantics of that backend and I don't know if there are any hidden gotchas with the naive solution.

[chrisduerr]

From what I've seen skimming the macOS code this shouldn't be too hard to implement

I'd be curious what makes you say that. I've looked at the macOS code and it looks to me like it would require a major rework to implement this.

Currently the callback for run is stored globally in a static variable, so it's not possible to implement run_return because of the lifetime guarantees, so we can't make that static since it needs to return the values moved into the closure.

That's the main reason why I haven't looked at it yet, since it seems like it requires significant work to get done and I just do not have that time at the moment.

[Osspial]

Currently the callback for run is stored globally in a static variable, so it's not possible to implement run_return because of the lifetime guarantees, so we can't make that static since it needs to return the values moved into the closure.

Can't we use transmute to artificially extend the closure's lifetime (this is explicitly supported behavior), and then unset the global closure at the end of run_return?

[chrisduerr]

Can't we use transmute to artificially extend the closure's lifetime (this is explicitly supported behavior), and then unset the global closure at the end of run_return?

Honestly in my opinion that sounds like very unidiomatic Rust code that would be very prone for serious issues. Sure transmute can do that, but it's also marked as unsafe for a very good reason.

I'm not sure why the macOS code was written the way it is. But at that point I feel like we'd have C code, not Rust code. A static global reference to a function which requires to be manually freed is much closer to what you'd do in C than Rust in my experience.

[Osspial]

[chrisduerr]

[Osspial]