Make instance variables even simpler type-wise

[madsmtm]

We use IvarDrop mostly because Box is #[fundamental], which means we can't ensure that no Encode impl exist for it (even though we know that would very likely be wrong).

Instead, we might be able to (ab)use HRTBs, see this playground link for the general idea. This is also what bevy uses for their IntoSystem trait.

Ideally we'd be able to do avoid IvarDrop, IvarEncode and IvarBool altogether, and just do (with or without the ivar names):

ivar1: Ivar<Box<i32>, "ivar1">,
ivar2: Ivar<i32, "ivar2">,
ivar3: Ivar<bool, "ivar3">,

Still need to figure out how to actually do that in a struct (playground).

[madsmtm]

Reminding myself why we can't add a zero-cost IvarAny<T>: drop(MyClass::alloc()) must be safe, which means that dealloc can be called before the class has actually initialized anything (and hence it will attempt to drop uninitialized data).

Maybe we could get by with just adding an extra, hidden IvarBool onto the class if any IvarAny<T> is present? And then we set that when initializing, and check it when deallocating? Though then we'd somehow have to control initializers a lot more, to ensure it is set automatically.

So maybe the "is initialized" flag has to be set on the IvarAny type itself? So it's actually enum IvarAny<T> { Allocated, Initialized(T) }, and then when calling Ivar::write we also change the state?

(This somewhat ties in with the drop flags that Rust has).

[madsmtm]

Todo: Figure out whether Swift uses drop flags on Objective-C compatible classes or not.

And if not, how Swift-created classes then are safely exposed to Objective-C which may allocate without initalizing, as well as how Swift handles unwinding through initializers.

[madsmtm]

A few Swift compiler details on this: swiftlang/swift#33743.

Doesn't explain what happens when Objective-C interop is enabled though.

[madsmtm]

Perhaps it would be best to revert the "instance variables should work transparently like struct fields" decision, since it seems brittle from a soundness perspective, and it introduces extra code in Deref which is really hard to debug, as well as possibly being a performance pitfall.

Instead, we could do something like:

declare_class!(
    struct MyClass;

    pub? struct MyClassIvars {
        ivar1: Cell<bool>,
        ivar2: AnyRustType,
    }

    unsafe impl ClassType for MyClass {
        type Super = NSObject;
        type Mutability = Mutable;
        const NAME: &'static str = "MyClass";
    }
);

// Generates
struct MyClass(NSObject);
// + Trait impls

impl Encode for MyClassIvars {
    const ENCODING: Encoding = {
        // Something calculated based on size/alignment of the ivars
    };
}

impl MyClass {
    const IVAR_NAME: &'static str = concat!("_", MyClass::NAME, "_ivars");
    static mut IVAR_OFFSET: isize = 0; // Will be set immediately after class creation

    pub? fn ivars(&self) -> &MyClassIvars { ... }
    pub? fn ivars_mut(&mut self) -> &mut MyClassIvars { ... }
}

// Usage:
let obj: Id<MyClass>;

// Loads the offset twice, though that _may_ be possible to optimize away
obj.ivars().ivar1.set(true);
obj.ivars().ivar2.any_rust_method();

// Guaranteed to be the most efficient
let ivars = obj.ivars();
ivars.ivar1.set(true);
ivars.ivar2.any_rust_method();

// The whole class is borrowed for the duration, but but disjoint access to the ivars is still possible
let mut ivars = obj.ivars_mut();
ivars.ivar1 = Cell::new(true);
ivars.ivar2.any_mutating_rust_method();

Advantages over having separate ivar1/ivar1_mut/ivar2/ivar2_mut methods:

• Only needs one instance variable, which makes the drop flag stuff much easier to incorporate.
• Allows disjoint access to mutable fields
• Nicely matches the solution outlined in declare_class!: Safer initializers #438

Disadvantages:

• Higher line-noise (users are going to call self.ivars() all the time in their declared methods)
• The ivar name may be confusing when debugging.

Though we may be able to mitigate the first by providing helper methods? Or maybe users should be encouraged to provide those themselves?

[madsmtm]

Or perhaps even:

struct MyClassIvars {
    ivar1: Cell<bool>,
    ivar2: AnyRustType,
}

declare_class!(
    struct MyClass;

    type Ivars = MyClassIvars;

    unsafe impl ClassType for MyClass {
        type Super = NSObject;
        type Mutability = Mutable;
        const NAME: &'static str = "MyClass";
    }

    // ...
);

Since we don't actually care about the contents of the ivars (it can even be an enum, or something wrapped in e.g. a RefCell if you intend to always access your ivars through that).

[madsmtm]

Okay so it turns out that Swift doesn't even try to handle the case where a class is not fully initialized - the following crashes because it tries to dereference a null pointer:

import Foundation

class Bar {
    func bar() {
        print("Bar.bar")
    }
}

@objc public class Foo: NSObject {
    var bar = Bar.init()

    deinit {
        print("deinit")
        self.bar.bar() // null pointer deref here
    }
}

#import "ProjectName-Swift.h" // Or however your bridging headers are set up

int main(int argc, const char * argv[]) {
    Foo* foo = [Foo alloc]; // Allocate, but don't initialize the object
    return 0;
}

Now I'm wondering if we can get away with doing the same if we put more restrictions on initializers, e.g. after #440? Though it would require going through some hoops to get unwind safety (Swift doesn't do unwinding, it just traps).

[madsmtm]

Here is a playground I made to see if it was possible to special-case types like Box<T>, so that we use the niche in there for the drop flag. Unfortunately, I don't think it is.

[madsmtm]

We could also go the crazy route of:

• impl Drop for Allocated<T> calls the NSObject dealloc routine instead of release.
• impl Drop for PartialInit<T> does the same as above, plus it manually deallocates any ivars on the current class.

Or perhaps even do method swizzling before calling release?

All of this would never be called in the usual cases where we don't unwind, so maybe swizzling could actually make sense?