Objective-Rust

This is going to be another one of those posts where I did something ridiculous and then show you how I got there, so let’s just get right to it.Yep, that’s Rust code with embedded Objective-C syntax, and it works. It is likely that the most heavily-optimized piece of code in Apple’s libraries is objc_msgSend, which takes a receiver, a selector, and the arguments to the method, does a (cached) lookup of the selector in the receiver’s class’s dispatch table(s), and then jumps directly to the appropriate, polymorphically-selected implementation of the method.There are more things the Objective-C runtime exposes, but messages are absolutely the most important.…Oh, one more thing. That means keywords with @ signs in front of them—one of the few symbols on the US keyboard that doesn’t already have a meaning in C—and a unique bracket-based “message send” syntax that takes a while to get used to:People almost universally think Objective-C syntax is ugly when they first see it, almost universally find it completely normal after a few years, and largely (though not almost universally) find idiomatic Swift easier to read even if they’re used to Objective-C.From this point on you’ll be expected to read Rust syntax without step-by-step explanations. this is just objective-c pic.twitter.com/dVQMYKKVTIWhat I wanted was for Objective-C’s messaging syntax, or something like it, to be valid anywhere in Rust code. (That’s probably why it’s bracketed in C as well.) Within the brackets, there’s basically two forms:If I were just matching that, I could use Rust’s original pattern-matching macros. But to take a whole block of code, and replace everything that looks like a message lock in that block…well, it might be possible with pattern-matching and quite a bit of recursion, but it’s going to be a lot easier to use procedural macros, a Rust macro interface written in Rust and used as a compiler plugin. But alas, the whole point was that Objective-C message syntax isn’t existing Rust syntax, and so only the normal proc_macro form works. So the simplest thing to do is put the macros in a second crate nested in the main one:5The top-level crate inline-objc depends on macros by relative path:6And inline_objc should re-export the macros so that clients don’t even need to think about all of this:(And the main.rs file isn’t necessary; it’s just for quick testing.)That’s all I have for now, though I’m still relatively new to Rust and so I stumbled over a few things that a more experienced Rust programmer / Cargo user would already know.The Rust blog has that high-level summary, “Procedural Macros in Rust 2018”.As mentioned, David Tolnay made a workshop repo for learning about procedural macros. I didn’t go through it myself but if you want a proper introduction with practice projects, this is probably a good place to start.For more serious Rust/Objective-C interop work, there’s the real objc crate, and Sheldon’s accompanying blog post, which is a lot more step-by-step than this one.When I tweeted about this toy project, Ryan McGrath responded with his own fun experiment Cacao, which builds on objc to provide Rust wrappers around AppKit and UIKit. I didn’t know it at the time, but the Servo project has their own project that wraps AppKit, core-foundation-rs.And as a last fun note, Mara Bos made a crate to allow inline Python code within your Rust code, though it (sensibly) doesn’t mix Python and Rust syntax. Both Swift and Rust go beyond the set of types and operations supported by C, much more than Objective-C’s little “cast objc_msgSend to the type of the method you’re actually calling”, and don’t (necessarily) make information about that available at runtime.