Refactoring MacPlatform and MacPlatformState

[tidely]

I've been looking at crates/gpui/src/platform/mac/platform.rs and I noticed a pattern with how the MacPlatformState is mutated. MacPlatform which is a wrapper around MacPlatformState with a Mutex.

struct MacPlatform(Mutex<MacPlatformState>);

All unsafe functions are implemented for MacPlatform and usage usually looks something like this (simplified example):

// impl MacPlatform
unsafe fn read_pasteboard(&self, pasteboard: *mut Object, kind: id) -> Option<&[u8]> { ... }

// impl Platform for MacPlatform
fn read_from_clipboard(&self) -> Option<ClipboardItem> {
    let state = self.0.lock();
    let pasteboard = state.pasteboard;

    let text = self.read_pasteboard(pasteboard, state.pasteboard_type)?;
    drop(state);
    Some(text)
}

If instead we implemented methods that interact with the state for the MacPlatformState instead of MacPlatform. We could change the signature for the methods from taking &self to &mut self. This is always the case anyway, since the state is behind a mutex, and we wouldn't need to redundantly pass elements from state to a method thats implemented on itself. Our api would turn into something like this:

// impl MacPlatformState
unsafe fn read_pasteboard(&mut self) -> Option<&[u8]> { ... }

// impl Platform for MacPlatform
fn read_from_clipboard(&self) -> Option<ClipboardItem> {
   // Explicit but example is very simple, could be replaced with:  self.0.lock().read_pasteboard()
    let state = self.0.lock();
    let text = state.read_pasteboard()?;
    drop(state);
    Some(text)
}

If the zed team is interested in a change like this, I'd be willing to work on a PR.

[ConradIrwin]

Seems like a reasonable idea, but not sure the best way to make this happen. You could send PRs, but all platform code changes carry a relatively high risk because of the lack of automated testability, and the comparative ease of creating dead-locks in rust, or crashes in macOS; so it's hard for us to prioritize them unless they're fixing known other problems.

One thing to watch out for is re-entrancy. If you call a macOS function that can call an application delegate method then you must make sure to drop the lock first.