Open Radar

 
Summary:
Currently we are able to use dynamic dispatch on classes declared using @objc or inheriting from NSObject.

This should be extended to the rest of the language, so that we can use objectOrStruct.methodName?(...)

Ideally, this should be extended so that it is possible to write objectOrStruct.methodName? regardless whether the object/struct implements a protocol with methodName or not.

The underlying implementation can be allowed to differ depending on the actual object.

For example, for structs and native swift classes, we could use  (the future) reflection machinery to do this in the Java way, without involving the ObjC runtime. This is a bit slow but will work.

For @objc / NSObject we get the fast ObjC dispatch.

In order to fully promote this, I also suggest dropping the @objc syntax, which makes dynamic dispatch seem loosely bolted on.

Example syntax:

// For ObjC-style classes
dynamic class MyClass {
}

// Or conversely instead annotate swift classes
static class MyClass {
}

For protocols to be exported to ObjC

// or possibly @objc - it makes sense here
@exported protocol MyProtocol {
}

Native swift protocols should obviously support optional natively.

To ensure fine grained control over dynamic/static dispatch (and perhaps remove the need for dynamic/static class distinctions) we could annotate methods as @final (no virtual dispatch, always possible to inline when referenced directly from class) @static (vtable or inlined, but slow dynamic dispatch via reflection) and @dynamic (ObjC style fast dynamic dispatch)

Either @static or @dynamic would obviously be default. Swift could decide depending on what annotations are present if the class is registered with objc or not.

@exported (@objc) on the class would only determine if the class is exported to ObjC or not.
Alternatively, everything is exported by default and you need to annotate with @internal in order to hide it from ObjC