<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="">Any chance at a 4.1 or a 4.2 round this year?</div><div class=""><br class=""></div><div class="">-- E</div><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 5, 2017, at 1:16 AM, Xiaodi Wu 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="">I hope so! We'll have to wait a bit for the core team to outline Swift 5 priorities.<br class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Jun 5, 2017 at 00:24 Pranshu Goyal <<a href="mailto:pranshu.goyal@novanet.net" class="">pranshu.goyal@novanet.net</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">Any hopes for it in future?</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On 4 June 2017 at 20:40, Xiaodi Wu <span dir="ltr" class=""><<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">No.<div class="m_-6985791186084394326HOEnZb"><div class="m_-6985791186084394326h5"><br class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Sun, Jun 4, 2017 at 10:07 Pranshu Goyal via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">Is this proposal in the pipeline for Swift 4?</div><div class="gmail_extra"></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On 1 April 2017 at 12:03, Adrian Zubarev via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="m_-6985791186084394326m_5887656818902584735m_-4102931754312293341m_-4009237607338995170bloop_markdown"><p class="">First, you should fix the indent in the code samples. Second, remove any access modifier from inside a protocol. Third, we don’t support default implementations directly inside protocols yet, so that’s a not valid example.</p><p class="">Now my personal concerns. As far as I can tell XIB files in an iOS Project are meant for UIViewControllers in first place, but it’s a common case that they are also used to create reusable UIViews. The downside of that abusage is view hierarchy clustering. Most developer creating a view of <code class="">Self</code> in <code class="">Self</code>, which smells to me like really bad code.</p>
<pre class=""><code class="">MyCustomView // This view is useless
+ MyCustomView
+ CustomSubview1
+ CustomSubview1 // This is probably a dead IBOutlet
</code></pre><p class="">In fact Xcode does not use the initializer from <code class="">NSCoding</code> to show a live rendered view inside interface builder, instead it will call a UIViews designated initializer <code class="">init(frame:)</code>. That results that a lot of the developer write similar code like in the following snippet:</p>
<pre class=""><code class="m_-6985791186084394326m_5887656818902584735m_-4102931754312293341m_-4009237607338995170swift">// This pattern results in a similar view cluster like mentioned above
class MyCustomView : UIView {
override init(frame: CGRect) {
let view = loadSomehowFromNib()
self.addSubview(view)
}
}
</code></pre><p class="">To solve this problem we’d need some functionality of factory initializers. I believe as proposed the factory initializer won’t solve that problem, because everything would be still restricted to a special initializer annotated with <code class="">factory</code>.</p><p class="">Personally I would want to write something like this instead.</p>
<pre class=""><code class="m_-6985791186084394326m_5887656818902584735m_-4102931754312293341m_-4009237607338995170swift">class MyCustomView : UIView {
override init(frame: CGRect) {
// Instantiating from a Nib file will call `init(coder:)` on MyCustomView
self = loadSomehowFromNib() // assuming () -> MyCustomView
//
self.frame = frame
}
}
</code></pre><p class="">This should resolve the clustering issue by assigning the returned instance from the function to <code class="">self</code> and create a correct view hierarchy.</p>
<pre class=""><code class="m_-6985791186084394326m_5887656818902584735m_-4102931754312293341m_-4009237607338995170swift">+ MyCustomView
+ CustomSubview1
</code></pre><span class="m_-6985791186084394326m_5887656818902584735m_-4102931754312293341HOEnZb"><font color="#888888" class=""><div class=""><br class="webkit-block-placeholder"></div></font></span></div><div class="m_-6985791186084394326m_5887656818902584735m_-4102931754312293341m_-4009237607338995170bloop_original_html"><span class="m_-6985791186084394326m_5887656818902584735m_-4102931754312293341HOEnZb"><font color="#888888" class=""><div id="m_-6985791186084394326m_5887656818902584735m_-4102931754312293341m_-4009237607338995170bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><br class=""></div> <br class=""> <div id="m_-6985791186084394326m_5887656818902584735m_-4102931754312293341m_-4009237607338995170bloop_sign_1491027029786638848" class="m_-6985791186084394326m_5887656818902584735m_-4102931754312293341m_-4009237607338995170bloop_sign"><div style="font-family:helvetica,arial;font-size:13px" class="">-- <br class="">Adrian Zubarev<br class="">Sent with Airmail</div></div></font></span><div class=""><div class="m_-6985791186084394326m_5887656818902584735m_-4102931754312293341h5"> <br class=""><p class="m_-6985791186084394326m_5887656818902584735m_-4102931754312293341m_-4009237607338995170airmail_on">Am 17. März 2017 um 17:26:29, Riley Testut via swift-evolution (<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite" class="m_-6985791186084394326m_5887656818902584735m_-4102931754312293341m_-4009237607338995170clean_bq"><span class=""><div dir="auto" class=""><div class=""></div><div class="">
<div class="">
<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" target="_blank" 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" target="_blank" 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="">
<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="">
<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" target="_blank" class="">swift-evolution@swift.org</a>>
wrote:</span><br class=""></blockquote>
<blockquote type="cite" class=""><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=""><br class=""></blockquote>
<blockquote type="cite" class=""><span class="">Charles</span><br class=""></blockquote>
<blockquote type="cite" class=""><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" target="_blank" class="">swift-evolution@swift.org</a>>
wrote:</span><br class=""></blockquote>
</blockquote>
<blockquote type="cite" class="">
<blockquote type="cite" class=""><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=""><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=""><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=""><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=""><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=""><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=""><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=""><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=""><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=""><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=""><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=""><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=""><br class=""></blockquote>
</blockquote>
<blockquote type="cite" class="">
<blockquote type="cite" class=""><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" target="_blank" class="">phausler@apple.com</a>>
wrote:</span><br class=""></blockquote>
</blockquote>
</blockquote>
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><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=""><br class=""></blockquote>
</blockquote>
<blockquote type="cite" class="">
<blockquote type="cite" class=""><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" target="_blank" class="">brent@architechies.com</a>>
wrote:</span><br class=""></blockquote>
</blockquote>
</blockquote>
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><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=""><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=""><br class=""></blockquote>
</blockquote>
<blockquote type="cite" class="">
<blockquote type="cite" class=""><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=""><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" target="_blank" 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" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class="">
</blockquote>
</blockquote>
<blockquote type="cite" class=""><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" target="_blank" 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" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class="">
</blockquote>
</div>
</blockquote>
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></span></blockquote></div></div></div><div class="m_-6985791186084394326m_5887656818902584735m_-4102931754312293341m_-4009237607338995170bloop_markdown"><div class=""><br class="webkit-block-placeholder"></div></div></div><br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div></div><div class="gmail_extra">-- <br class=""><div class="m_-6985791186084394326m_5887656818902584735m_-4102931754312293341gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class=""><font color="#999999" size="2" face="georgia, serif" class=""><i class="">Pranshu Goyal</i></font><div class=""><font color="#999999" size="2" face="times new roman, serif" class=""><i class="">iOS Developer</i></font></div><div class=""><font color="#999999" size="2" face="times new roman, serif" class=""><i class="">tlkn</i></font></div></div></div>
</div>
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
</div></div></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="m_-6985791186084394326gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class=""><font color="#999999" size="2" face="georgia, serif" class=""><i class="">Pranshu Goyal</i></font><div class=""><font color="#999999" size="2" face="times new roman, serif" class=""><i class="">iOS Developer</i></font></div><div class=""><font color="#999999" size="2" face="times new roman, serif" class=""><i class="">tlkn</i></font></div></div></div>
</div>
</blockquote></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>