I'd like to contribute

[madsmtm]

Hi @nvzqz!

I'd like to contribute to this library in at least the coming 6 months. My motivation would be to create a safe(er) replacement for objc and related crates (I tried improving that first, see SSheldon/rust-objc#101) that I can use in winit and personal projects.

But before I start throwing code at you I'd like to get an estimated answer to the following questions, just to get a feel for the state of the library (and you 😉):

• Do you want to receive and review PRs?
• How do you feel about the project right now? Burnt out or do you still believe in it?
• What are your long-term plans for this library?
• Would you be open to putting it in a GitHub organization at some point (or asked another way, how much "ownership" of the library do you feel?)

Also, would you be open to supporting declaring custom classes? This is required in many cases for implementing delegates. If yes, there's at least three parts to it:

• The declaration part itself. See objc::declare for an example implementation.
• Letting users choose which traits are implemented for their own custom classes; this would require some form of subclassing, maybe the design that objc-foundation uses (having trait INSString and concrete implementors NSString and NSMutableString), or something else entirely.
• Message-sending macros would have to be public API

Concrete improvements I would like to make is:

• Rework Arc to have a notion of ownership, so that we can have safe mutability (a lot like in objc_id)
• Add a AutoreleasePool type to let you return references to autoreleased items. See Make autoreleasepool take the pool as a parameter SSheldon/rust-objc#103 for more info. Would allow a safe NSString::to_str.
• Add helper types to indicate operations that are only safe on the main thread and/or after the NSApplication has been initialized
• Maybe implement some of the generic types in Foundation
• Bringing the exception and verify_message features of objc to this crate as well
• Improve testing of NSString (especially the hacky macro)
• Start adding some AppKit classes, at least for the things I need 😉

Hope you have a nice day!

[mikeumus]

@madsmtm 🙌
@nvzqz 👋😃

[madsmtm]

I started work in a private fork (of objc), will update you @mikeumus when I've got something to show for

[madsmtm]

Hey, I've released my fork of objc now: objc2.

It hasn't change much from objc in the API surface, and is missing a lot of things that fruity has, namely:

• Static NSStrings (probably won't come for a while because of issues with it's stability, and it probably also has to be adapted to work on GNUStep), tracked in Static NSString madsmtm/objc2#53
• Ergonomic Foundation types, tracked in Downgrading using Deref madsmtm/objc2#58
• Reference-counting type that can work generically with Core Foundation, Objective-C and libdispatch types (Probably won't happen, we have objc2::rc::Id which works with Objective-C types, and then one should create new types for the others).

And fruity also has a lot of libraries, which is out of scope for objc2, e.g.:

• Core Foundation types
• Core Graphics types
• libdispatch
• ...

But still, you may find it useful ;)