Mads Marquart

> I've become disillusioned that much of this is meaningful/valuable. I'm sad to hear that, but I've been there myself, it's fully understandable! > Trying to write safe wrappers around...

> worth investigating directly bridging between Rust and Swift instead of relying on an Objective-C middle layer Definitely interesting, though I think there's merit in having both this library and...

@SSheldon I'm sorry to press on but at some point I and others need to know how to move forwards. It is totally cool if you consider this library feature...

I fully understand and very much respect that you want to be conservative on updating `objc`! When we do get there, we could perhaps also utilize the [semver trick](https://github.com/dtolnay/semver-trick#the-semver-trick) to...

Alright, I yield, I'll take my suggestions elsewhere / create a fork. On a related note, how would you feel (a license is one thing, being considerate is another :wink:)...

Alright, so I went and made a fork (still quite WIP), and merged the linked projects into that: [`objc2`](https://github.com/madsmtm/objc2). The repository contains the following new crates: - `objc2` (`objc_id` and...

Oh, and a final thing, @SSheldon, then I won't bother you again for a while: Would you be willing to let me relicense your work under a dual MIT/Apache-2.0 license?...

> compiled Swift binaries access them the same way that Objective-C binaries do. Yeah, I suspected this would be the case, which means that a Rust/Swift bridge would not be...

`msg_send!` has no way to know what sending the `operatingSystemVersion` selector to `NSProcessInfo` could possibly return, so when you write `let os_version: *const Object`, you have the responsibility to ensure...

Can you elaborate on what you were unhappy with in `objc-id`? Was the problem that it didn't work for `cocoa`, or something else?