Some thoughts: <br><br>1 &quot;self =&quot; is better in inits because of a common pattern of configuring an object in the second init stage <br><br>2 since there is already an existing syntax for protocol implementation functions, the role of init keyword  is basically to stand for &quot;empty function name&quot; syntax. This sounds interesting. <br><br>3 you can also add init to the protocol (with Self return value and required keyword) for some interesting effects. <br><br>4 final init, not class init (because init is already called on the class):<br><br>class BaseClass {<br>  init(x: ...) -&gt; Self // regular, inheritable init, Self can be omitted <br>  final init(y:...) -&gt; Self // Self always = BaseClass, can return Derived()<br><br>5 yes, that would nicely work with ObjC, even if that was not the original goal :)<br><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 8, 2015 at 02:24 Brent Royal-Gordon via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; Throughout its frameworks, Apple makes use of the “class cluster” pattern as a means to separate the public API out from the (potentially complex) internal representations of the data. Clients of the API simply use the public API, while under the hood a different implementation is chosen to most efficiently represent the provided initialization parameter values.<br>
&gt;<br>
&gt; Unfortunately, because initializers in Swift are not methods like in Objective-C, there is no way to specify what the actual return value should be (short of returning nil for failable initializers). This makes it *impossible* to actually implement the class cluster pattern in Swift.<br>
<br>
I’d actually like to put Objective-C interop aside for a moment. There are many class clusters in Objective-C, but most of them are things you rarely need to subclass yourself. When was the last time you wrote an NSArray subclass? What’s more interesting to me is how we can provide a similar native Swift pattern.<br>
<br>
Here’s my thinking.<br>
<br>
First of all, we call them “class” clusters, but there’s no reason this should be only for classes. A “class cluster” is basically a single API which offers access to many different implementations of an interface. The phrase “many different implementations of an interface” is a hint that we should be thinking about protocols.<br>
<br>
Here’s what I think Swift should support:<br>
<br>
        protocol HTTPParameterListType {<br>
                var all: DictionaryLiteral&lt;String, Strong&gt; { get }<br>
                subscript (name: String) -&gt; [String] { get }<br>
        }<br>
<br>
        // Various implementations include:<br>
        struct JSONParameterList: HTTPParameterList {...}<br>
        struct MultipartParameterList: HTTParameterList {…}<br>
        struct URLEncodedFormParameterList: HTTPParameterList {…}<br>
        struct QueryParameterList: HTTPParameterList {…}<br>
<br>
        extension HTTPParameterListType {<br>
                protocol init(request: NSHTTPRequest, bodyData: NSData) throws {<br>
                        switch request.valueForHTTPHeaderField(“Content-Type”).map({ MIMEType(rawValue: $0) }) {<br>
                        case .JSON?:<br>
                                return try JSONParameterList(data: bodyData)<br>
<br>
                        case .MultipartFormData?:<br>
                                return try MultipartParameterList(data: bodyData)<br>
<br>
                        case .URLEncodedForm?:<br>
                                return try URLEncodedFormParameterList(data: bodyData)<br>
<br>
                        default:<br>
                                return try QueryParameterList(request: request)<br>
                        }<br>
                }<br>
        }<br>
<br>
        // Usage:<br>
        self.parameters = HTTPParameterListType(request: request, bodyData: data)<br>
<br>
A `protocol init` in a protocol extension creates an initializer which is *not* applied to types conforming to the protocol. Instead, it is actually an initializer on the protocol itself. `self` is the protocol metatype, not an instance of anything. The provided implementation should `return` an instance conforming to (and implicitly casted to) the protocol. Just like any other initializer, a `protocol init` can be failable or throwing.<br>
<br>
Unlike other initializers, Swift usually won’t be able to tell at compile time which concrete type will be returned by a protocol init(), reducing opportunities to statically bind methods and perform other optimization tricks. Frankly, though, that’s just the cost of doing business. If you want to select a type dynamically, you’re going to lose the ability to aggressively optimize calls to the resulting instance.<br>
<br>
Perhaps this feature can then be extended back to classes, with a `class init` being an un-inherited initializer which uses `return` to give the caller a new object. `self` would be the class object, and only class variables and methods would be callable from it. But like I said, I’m not particularly interested in Objective-C interop right now.<br>
<br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>