<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">This was kind of my point - all current class initializers are allocating. Allowing non-allocating initializers would solve most cases, including factory methods.</div><div class=""><br class=""></div><div class="">The last else statement in your example (for a regular case) can definitely return a value from another initializer - e.g. init(reservingCapacity:).</div><div class=""><br class=""></div><div class="">I wouldn't go for the return statement, but rather assignment to self - this is more in line with to how the convenience initializers work - you can branch based on the input and call designated initializers accordingly.</div><div class=""><br class=""></div><div class="">The same way, you could assign to self and then access instance variables within self.</div><div class=""><br class=""></div><div class="">Taking your example, all returns would be assignment to self and the last branch of the if-else statement would read as follows:</div><div class=""><br class=""></div><div class="">self = self.init(reservingCapacity: cnt)</div><div class="">for idx in 0..<cnt {</div><div class=""> // It's OK now to access _storage as we've previously</div><div class=""> // assigned to self.<br class=""> _storage.append(objects[idx])<br class="">}</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 21, 2017, at 6:04 PM, Philippe Hausler <<a href="mailto:phausler@apple.com" class="">phausler@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">One concept to consider here is that the initializers that are factories may or may not replace self;</div><div class=""><br class=""></div><div class="">Take for example NSArray (inspired from the objective-c implementation but written in swift, but note this is not the only use case)</div><div class=""><br class=""></div><div class="">public init(objects: UnsafePointer<AnyObject>!, count cnt: Int) {</div><div class=""> if count == 0 && type(of: self) == NSArray.self {</div><div class=""> // specialized NSArray that does not contain any objects; it is a singleton so we dont need to allocate at all</div><div class=""> return __NSArray0.zeroElementSingleton</div><div class=""> } else if count == 1 type(of: self) == NSArray.self {</div><div class=""> // The single object version is more effecient since it does not need to indirect to a buffer</div><div class=""> return __NSArray1(objects.pointee)</div><div class=""> } else if type(of: self) == NSArray.self {</div><div class=""> return CFArrayCreate(kCFAllocatorSystemDefault, UnsafeMutablePointer<UnsafeRawPointer?>(objects), cnt, &kCFTypeArrayCallBacks)</div><div class=""> } else {</div><div class=""> _storage.reserveCapacity(cnt)</div><div class=""> for idx in 0..<cnt {</div><div class=""> _storage.append(objects[idx])</div><div class=""> }</div><div class=""> }</div><div class="">}</div><div class=""><br class=""></div><div class="">This would mean that in the cases of 0 elements when NSArray itself is created we can avoid allocating, when the count is 1 and it is an NSArray itself we can emit a more effecient storage, then when the type is immuatable we can fall to CF, and finally in the abstract case we can store elements in a buffer directly.</div></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 21, 2017, at 4:28 PM, Charlie Monroe via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I believe that this proposal is trying to solve something that can be solved by allowing assignment to self within convenience initializers. </div><div class=""><br class=""></div><div class="">Unfortunately, even convenience initializers are allocating which makes it harder to achieve with backward compatibility - though I'm not entirely sure what would be the consequences of turning them into non-allocating.</div><div class=""><br class=""></div><div class="">If it's not possible due to implementational details, I'd suggest to rather introduce a @nonallocating (or similar) annotation (keyword?) that can be placed on init methods and it would then require for self to be assigned during the initialization as long as the assigned value is subtype of the receiver:</div><div class=""><br class=""></div><div class="">@nonallocating init(x: Int) {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if x < 0 {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>self = NegativeMe(x: x)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>} else {</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>self = PositiveMe(x: x)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class="">}</div><div class=""><br class=""></div><div class="">Which is pretty much what the proposal is suggesting, but removes the "factory" keyword which may be a bit misleading or narrowly named.</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 21, 2017, at 4:49 PM, David Rönnqvist via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Forgive me if that has already been discussed in the email threads prior to the proposal, but what I’m missing from this proposal is a discussion of the problems factory initializers solve (other than the examples at the end) and an explanation of why factory initializers are the right solution to that/those problems in Swift.</div><div class=""><br class=""></div><div class="">I acknowledge that it’s a common pattern in many languages, but don’t find it a very strong argument as to why it should be built into the language. </div><div class=""> </div><div class="">Regards,</div><div class="">David</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 17 Mar 2017, at 17:26, Riley Testut via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><span class=""></span></div><div class=""><div class=""></div><div class="">Hi again everyone!</div><div class=""><br class=""></div><div class="">Now that Swift 4 Stage 2 proposals are being considered, I thought it might be time to revisit this proposal and see if it might align with the goals set forth for Swift 4.</div><div class=""><br class=""></div><div class="">As a quick tl;dr, this proposal describes a new "factory initializer" that would allow you to return a value from an initializer. This would have several benefits, as mentioned in the proposal itself as well as throughout this mailing list. For convenience, here's a link to the proposal on GitHub: <a href="https://github.com/rileytestut/swift-evolution/blob/master/proposals/NNNN-factory-initializers.md" class="">https://github.com/rileytestut/swift-evolution/blob/master/proposals/NNNN-factory-initializers.md</a></div><div class=""><br class=""></div><div class="">Would love to hear any more comments on this proposal, and if we feel this is appropriate for considering for Swift 4 I'll happily re-open the pull request!</div><div class=""><br class=""></div><div class="">Riley Testut</div><div class=""><br class="">On Nov 19, 2016, at 7:45 AM, arkadi daniyelian <<a href="mailto:arkdan@icloud.com" class="">arkdan@icloud.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><span class="">i would appreciate this feature.</span><br class=""><span class=""></span><br class=""><span class="">For unexperienced developers, its often hard to recognize *when* factory is a good fit to do the job, and how exactly approach the implementation. I imagine having this feature built into the language may help to choose and implement factory when its the right thing to do.</span><br class=""><span class=""></span><br class=""><blockquote type="cite" class=""><span class="">On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Is there any chance of reviving this? It seems to me that since this would require Swift initializers to be implemented internally in such a way that they can return a value (as Objective-C init methods do), it may affect ABI stability and thus may be germane to the current stage of Swift 4 development.</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Charles</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Recently, I proposed the idea of adding the ability to implement the "class cluster" pattern from Cocoa (Touch) in Swift. However, as we discussed it and came up with different approaches, it evolved into a functionality that I believe is far more beneficial to Swift, and subsequently should be the focus of its own proposal. So here is the improved (pre-)proposal:</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""># Factory Initializers</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">The "factory" pattern is common in many languages, including Objective-C. Essentially, instead of initializing a type directly, a method is called that returns an instance of the appropriate type determined by the input parameters. Functionally this works well, but ultimately it forces the client of the API to remember to call the factory method instead, rather than the type's initializer. This might seem like a minor gripe, but given that we want Swift to be as approachable as possible to new developers, I think we can do better in this regard.</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Rather than have a separate factory method, I propose we build the factory pattern right into Swift, by way of specialized “factory initializers”. The exact syntax was proposed by Philippe Hausler from the previous thread, and I think it is an excellent solution:</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">class AbstractBase {</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""> public factory init(type: InformationToSwitchOn) {</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""> return ConcreteImplementation(type)</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""> }</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">}</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">class ConcreteImplementation : AbstractBase {</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">}</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Why exactly would this be useful in practice? In my own development, I’ve come across a few places where this would especially be relevant:</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">## Class Cluster/Abstract Classes</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">This was the reasoning behind the original proposal, and I still think it would be a very valid use case. The public superclass would declare all the public methods, and could delegate off the specific implementations to the private subclasses. Alternatively, this method could be used as an easy way to handle backwards-compatibility: rather than litter the code with branches depending on the OS version, simply return the OS-appropriate subclass from the factory initializer. Very useful.</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">## Protocol Initializers</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Proposed by Brent Royal-Gordon, we could use factory initializers with protocol extensions to return the appropriate instance conforming to a protocol for the given needs. Similar to the class cluster/abstract class method, but can work with structs too. This would be closer to the factory method pattern, since you don’t need to know exactly what type is returned, just the protocol it conforms to.</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">## Initializing Storyboard-backed View Controller</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">This is more specific to Apple Frameworks, but having factory initializers could definitely help here. Currently, view controllers associated with a storyboard must be initialized from the client through a factory method on the storyboard instance (storyboard. instantiateViewControllerWithIdentifier()). This works when the entire flow of the app is storyboard based, but when a single storyboard is used to configure a one-off view controller, having to initialize through the storyboard is essentially use of private implementation details; it shouldn’t matter whether the VC was designed in code or storyboards, ultimately a single initializer should “do the right thing” (just as it does when using XIBs directly). A factory initializer for a View Controller subclass could handle the loading of the storyboard and returning the appropriate view controller.</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Here are some comments from the previous thread that I believe are still relevant:</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">On Dec 9, 2015, at 1:06 PM, Philippe Hausler <<a href="mailto:phausler@apple.com" class="">phausler@apple.com</a>> wrote:</span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">I can definitely attest that in implementing Foundation we could have much more idiomatic swift and much more similar behavior to the way Foundation on Darwin actually works if we had factory initializers.</span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">On Dec 7, 2015, at 5:24 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:</span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">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.</span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">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.</span><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">I’d love to hear everyone’s thoughts on this!</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Best,</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Riley Testut</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">_______________________________________________</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">swift-evolution mailing list</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">_______________________________________________</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">swift-evolution mailing list</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></blockquote></div></blockquote></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>