Here's a very quick summary of the reasons cited in this article:

1. Mock objects

There's two different types of mocking. The first is where you know ahead of time what you need to mock, and this type is largely equivalent to just subclassing the desired class (except any methods called directly or indirectly by the class itself will bypass the mock). This could be achieved by implementing basically implicit delegation, where the invocation of any methods that an object does not respond to will be replaced by the same invocation on a designated property of the object. This could in fact be achieved today with conversion routines (which are undocumented and technically unsupported, so file a radar if you want to keep them), except when testing the object for its class or protocol support. So the language would have to add special support for this in order to have a true proxy object that pretends to be an instance of the target class.

The second is dynamic mocking, where you add behavior to the mock object at runtime. This I believe is what OCMock is doing. It's effectively equivalent to implementing every single method of the target class, and looking up any invocations of the method in an internal table of closures, falling back to calling the target class's implementation if there is no internal closure. Again, this would need support for class/protocol testing. And again, the language could certainly add support for this without message passing, by basically generating the code for what I just described.

It seems reasonable to me to request support for mock objects itself, without requiring message passing.

2. Swizzling

I'm really _really_ glad Swift's class model does not allow for this. Granted, you can still monkeypatch it at runtime the same way you can patch C code, but it's hard enough and esoteric enough that people will generally not do it.

Swizzling is a really bad idea. Every example given for why the author wants Swizzling is an example of something that you should not do. Changing Frameworks behavior, or injecting into apps and changing app behavior, is a Bad Thing™. When allowed, it's a major source for instability and crashes, and other bad behavior. For example, recently there's been a big resurgence in interest in unauthorized Xcode plugins, but Xcode doesn't have plugin support for a reason. Xcode plugins are a great way to make Xcode behave badly or crash. For example, Spark Inspector[1] installs an Xcode plugin on first launch (without asking!) that adds a menuitem to Xcode. And when Xcode 5.0 came out, it started crashing on launch for people who had the Spark Inspector plugin installed. And I guarantee you most people who experienced the crash did not know it was Spark Inspector's fault and blamed Xcode.

[1]: http://sparkinspector.com

Similarly, GPGMail is a Mail.app plugin that adds GPG support. Mail actually has official plugin support, although I believe it's pretty limited, and GPGMail ends up swizzling a bunch of stuff in the Compose window. Right now on OS X 10.10 Yosemite, GPGMail causes Mail.app to crash because of the swizzles (yes it's a beta OS, but the crash is entirely the fault of GPGMail, not the beta OS).

Simply put, swizzling is a horrible runtime hack that is possible in Obj-C, but is abused to do things that it shouldn't, and can cause all sorts of problems. It's definitely not something I want Swift to support.

3. Configuration

This doesn't require message-passing. In fact, the only language support one might want is a way to easily build a table that maps from variable name to getter/setter closure, although doing it in a type-safe fashion seems relatively problematic (the trivial solution is to use Any in the setter closure and fail if the input value is the wrong type, and the getter closure would of course just return Any as well). But even that's just a bit of a nice-to-have and relatively esoteric; you can certainly build such a table by hand.

And of course there are better ways to design this once you've actually defined how you expect your configuration to work (this article does not go into detail). One possible suggestion would be something like a JSON blob that defines key/value pairings that a given object should be updated with. This could in fact be implemented as a protocol on configurable objects, something like

protocol Configurable {
func configure_with(json: Dictionary<String,JSON>)
}

where we're assuming there's already a JSON library that has a datatype called JSON that represents the parsed JSON data. The object itself would then be responsible for checking if each of its properties exists in the dictionary and updating with the mapped-to JSON value (and asserting or ignoring if the type is wrong, depending on preference). This would actually be a lot more flexible than converting strings to methods, because it would allow for defining custom keys that do various transformations on the value, or that update multiple properties from one key, etc.

The one language feature that would help here would be support for `deriving`, which is to say, a way to derive the implementation of a protocol on a given type. Haskell and Rust both support this (I would assume other languages do too but that's what I know of off the top of my head). Of course, in Rust, only traits (protocols) known to the compiler can be derived. I am unclear how it works in Haskell. Ideally if Swift were to gain deriving support there would be some way of extending support to your own protocols, but right now it's very unclear how to properly handle metaprogramming in Swift. Regardless, this seems like a post-1.0 feature, and is not necessary for doing configuration.

4. Remote Methods

I am unclear what the author is asking for Swift to support here. Some kind of built-in distributed objects, like NSDistributedObject and the in/out/inout annotations in Cocoa, is a bad idea, as we have learned from NSDistributedObjects. The author's example of mapping IRC commands to actions seems to be completely unrelated to any sort of language support for this. For that example I'd just have e.g. an IRCEndpoint object that I would register closures with to handle various messages, and the closures can do whatever they want.

5. Runtime Metaprogramming

This is a dangerous topic. Runtime metaprogramming can do interesting stuff, but it's also usually considered to be rather hacky, potentially dangerous, and almost always a bad idea. Among Obj-C programmers that I respect, the general opinion is that if your code includes

#import <objc/anything.h>

then you've done something wrong, with the only exception being using associated objects (and even there, associated objects are typically considered a solution of last resort).

The author provides a link to a youtube video as an example of something cool you can do with runtime metaprogramming. I am not willing to sit through a 49 minute video, but skimming through it suggests that the idea is to have some sort of class that represents a word and autogenerate methods to conjugate the words. I think. In any case, my impression here is that the runtime metaprogramming is actually a poor man's compile-time metaprogramming. Compile-time metaprogramming is very powerful, but also hard to get right. It's something I think Swift needs, but it's also something that will take a while to design correctly, and is definitely a post-1.0 feature. As an example of how this is powerful, Rust provides compile-time metaprogramming via "syntax extensions", which are dylibs compiled from specially-annotated Rust libraries that are loaded directly into the compiler (which is written in Rust) and given full access to the AST. With this functionality, one of the libraries distributed with Rust is libregex, an re2 regular expression library, and this library provides the regex!() syntax extension that compiles the regex at compile-time and generates native code for matching (as opposed to the normal instruction-based virtual machine for runtime-parsed regexes).

---

Turns out I'm out of time. I think I covered basically everything in the article though.

tl;dr: Swift doesn't need message passing.