Merge `#[method(...)]` and `#[method_id(...)]`

[madsmtm]

Maybe we should reconsider whether it makes sense to keep those to separate? It would make it much easier for the user if they were merged. An argument for keeping them separate is compilation speed, since for #[method_id(...)] we know the we don't need to run the const code to check the selector? Though since we're specifying it anyhow in header-translator, perhaps we can just keep doing that.

EDIT: A quick test shows that getting rid of method families is a fairly big compile time regression. But I think we could still merge these, we can just choose to keep the method families in (and perhaps make it public, something like #[method(abc:def:, family = none)] could be cool).

I'm unsure of how much of an influence the selector checking has, will need to do an experiment to verify.

Note: All of this is easily solved by just checking the syntax tokens, but that is fundamentally brittle, so we should avoid going that route - it should ideally be handled in the type-system!

[madsmtm]

We should also consider merging msg_send! and msg_send_id!.

[madsmtm]

If performance allows, it does make sense to merge #[method(...)] and #[method_id(...)], both in extern_class!, extern_protocol! and declare_class!.

But I'm pretty sure there is value in keeping msg_send! and msg_send_id! separate, both for type-inference purposes, as well as for documentation.

[madsmtm]

I think that for documentation and simplicity purposes it makes sense to actually remove the argument/return conversion functionality from msg_send! and msg_send_id!, and instead direct users towards extern_methods!.

This would likely be easier to explain, and it means there's never a hidden cost to the basic macros.

Concretely, this would enable us to design things like:

mod encode {
    pub trait Encode {}
    pub trait RefEncode {}
    pub trait OptionEncode {}

    pub trait EncodeReturn: Sealed {}
    impl EncodeReturn for T: Encode {}
    impl EncodeReturn for () {}

    pub trait EncodeArgument: Sealed {} // Future-proofing
    impl EncodeArgument for T: Encode {}

    pub trait EncodeArguments: Sealed {}
    impl EncodeArguments for (T: EncodeArgument, ...) {}
}

pub trait Message: RefEncode {}
pub trait ClassType: Message {}
pub trait ProtocolType {}

mod runtime { // Or message, or somewhere else
    pub trait Receiver: Sealed + Encode {
        fn send_message(self, sel: Sel, args: impl EncodeArgument) -> impl EncodeReturn;
    }
    impl Receiver for &T: Message {}
    // ... similar to MessageReceiver, except without implementations for `&Id<T>`

    pub trait MethodImplementation {
        type Receiver: Receiver;
        type Arguments: EncodeArguments;
        type Return: EncodeReturn;
    }
    // impl for extern functions with those types
}

mod convert { // private for now, used by extern_methods! and declare_class!
    trait ConvertReceiver<RS> {}
    impl ConvertReceiver<New> for T: Receiver {}
    impl ConvertReceiver<Init> for T: Receiver {}
    impl ConvertReceiver<Init> for Allocated<T> {} // somehow restrict to only when the return type is `Id<T>`?
    impl ConvertReceiver<Alloc> for &AnyClass {}
    impl ConvertReceiver<CopyOrMurCopy> for T: Receiver {}
    impl ConvertReceiver<Other> for T: Receiver {}

    trait ConvertReturn<RS> {}
    impl ConvertReturn<RS> for T: EncodeReturn {}
    impl ConvertReturn<RS> for bool {}
    impl ConvertReturn<New> for Id<T> {}
    impl ConvertReturn<Init> for Id<T> {}
    impl ConvertReturn<Alloc> for Allocated<T> {}
    impl ConvertReturn<CopyOrMurCopy> for Id<T> {}
    impl ConvertReturn<Other> for Id<T> {}

    trait ConvertArgument {}
    impl ConvertArgument for T: EncodeArgument {}
    impl ConvertArgument for bool {}
    impl ConvertArgument for &mut Id<T> {}
    trait ConvertArguments {}

    trait ConvertReturnResult<RS> {}
    impl ConvertReturnResult<RS> for () {}
    impl ConvertReturnResult<RS> for Id<T>
    where Self: ConvertReturn<RS> {}
    impl ConvertReturnResult<Alloc> for Allocated<T> {}

    struct MethodKind;
    struct ClassFnKind;
    struct MethodResultKind;
    struct ClassFnResultKind;
    struct MethodSuperKind;
    // ... more super

    // For extern_methods!
    trait Send<RS, Receiver, Return> {
        fn send_message(obj: Receiver, sel: Sel, args: impl ConvertArguments) -> Return;
    }

    impl Send<RS, Receiver: ConvertReceiver<RS, Inner = impl Message>, Return: ConvertReturn<RS>> for MethodKind {}
    impl Send<RS, Receiver: ConvertReceiver<RS, Inner = AnyClass>, Return: ConvertReturn<RS>> for ClassFnKind {}
    impl Send<RS, Receiver: ConvertReceiver<RS, Inner = impl Message>, Return: ConvertReturnResult<RS>> for MethodResultKind {}
    // ...

    // For declare_class!
    // 
    // This mirrors on a yet in-progress improvement in declare_class! to allow this rewriting,
    // don't worry if you don't know what this does.
    trait ConvertFn<RS, Kind> {
        type ExternFn: MethodImplementation;
    }
    impl ConvertFn<RS, MethodKind> for fn(impl Receiver, T: ConvertArgument...) -> R: ConvertReturn<RS> {}
    impl ConvertFn<RS, ClassFnKind> for fn(T: ConvertArgument...) -> R: ConvertReturn<RS> {}
    // ...
}

The big benefit here being that the extern_methods! implementation and the declare_class! implementation can share a lot of logic, and that we have a sort of "split" between the fundamentals and the conversion niceties that we've added on top - both should hopefully make this mess easier to maintain.

---

A big challenge is how to properly bind the receiver and the return type together in init methods. Concretely, Clang's docs says:

init methods must be instance methods and must return an Objective-C pointer type. Additionally, a program is ill-formed if it declares or contains a call to an init method whose return type is neither id nor a pointer to a super-class or sub-class of the declaring class (if the method was declared on a class) or the static receiver type of the call (if it was declared on a protocol).

The way we currently handle this is to require the T: Message in the receiver and the return type to be the same.

But perhaps we could consider dropping that, and just decide not to handle the requirement at all, and instead expect the user to write the correct type? That would permit more correct code to work with the macros, though it may also lead to mistakes?

[madsmtm]

If we choose to drop support for conversions in msg_send!, then it probably makes sense to bring back msg_send_bool!.