You can work around this by using #selector(UIViewController.init as () -> UIViewController).

cc @DougGregor

Comment by Marc Knaup (JIRA)

Still not working in swift-DEVELOPMENT-SNAPSHOT-2017-09-26-a-osx but by now with a different error message:

import UIKit
#selector(UIViewController.init())

// error: argument of '#selector' does not refer to an '@objc' method, property, or initializer

Since init() is inherited from NSObject it should be a valid @objc initializer.

Given that this would be a change in the language semantics, it should go through swift-evolution.

Comment by Marc Knaup (JIRA)

What would be a change in semantics here?

#selector(NSObject.init()) and #selector(NSObject()) also don't work with the same error, but NSObject's init() is an ObjC initializer, isn't it?

Well, it's making some ill-formed code well-formed, and means that the expression

UIViewController.init()

has a different meaning within #selector than it does outside of #selector.

Comment by Marc Knaup (JIRA)

I understand. But why is that a problem?

#selector(UIViewController.init()) and alike isn't valid code at the moment anyway and results in a compile error which is not helpful.

The way I understand #selector is that it gives me a Selector to whatever method/initializer/property I put in there. Why should that no-arg example above be treated differently than #selector(UIViewController.init(_:))? Also Swift and Xcode both refer to it as init() for example in #function and in auto-completion. Why would a user expect .init() to be executed but not {{.init(: )}}_?

This is inconsistent and confusing.

To sum it up - the actual issue is still the same:
It's not possible to refer to a zero-argument initializers / methods if there is another initializer / method with the same name. Unless you add a cast to fix the ambiguity.