Re: [swift-evolution] [Proposal] Factory Initializers

Any chance at a 4.1 or a 4.2 round this year? -- E > On Jun 5, 2017, at 1:16 AM, Xiaodi Wu via swift-evolution > wrote: > > I hope so! We'll have to wait a bit for the core team to outline Swift 5 > priorities. > > > On Mon, Jun 5, 2017 at 00:24 Pranshu Goyal

Re: [swift-evolution] [Proposal] Factory Initializers

I hope so! We'll have to wait a bit for the core team to outline Swift 5 priorities. On Mon, Jun 5, 2017 at 00:24 Pranshu Goyal wrote: > Any hopes for it in future? > > On 4 June 2017 at 20:40, Xiaodi Wu wrote: > >> No. >> >> >> >> On Sun, Jun

Re: [swift-evolution] [Proposal] Factory Initializers

Any hopes for it in future? On 4 June 2017 at 20:40, Xiaodi Wu wrote: > No. > > > > On Sun, Jun 4, 2017 at 10:07 Pranshu Goyal via swift-evolution < > swift-evolution@swift.org> wrote: > >> Is this proposal in the pipeline for Swift 4? >> >> On 1 April 2017 at 12:03, Adrian

Re: [swift-evolution] [Proposal] Factory Initializers

No. On Sun, Jun 4, 2017 at 10:07 Pranshu Goyal via swift-evolution < swift-evolution@swift.org> wrote: > Is this proposal in the pipeline for Swift 4? > > On 1 April 2017 at 12:03, Adrian Zubarev via swift-evolution < > swift-evolution@swift.org> wrote: > >> First, you should fix the indent in

Re: [swift-evolution] [Proposal] Factory Initializers

Is this proposal in the pipeline for Swift 4? On 1 April 2017 at 12:03, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote: > 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 >

Re: [swift-evolution] [Proposal] Factory Initializers

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. Now my personal concerns. As far as I can tell XIB files in an iOS

Re: [swift-evolution] [Proposal] Factory Initializers

> On 01 Apr 2017, at 01:35, Riley Testut via swift-evolution > wrote: > > >> On Mar 20, 2017, at 8:07 PM, Greg Parker wrote: >> >> This needs more explanation. It is allowed for a subclass to implement a >> convenience initializer that has the

Re: [swift-evolution] [Proposal] Factory Initializers

Sent from my iPhone > On 1 Apr 2017, at 00:35, Riley Testut via swift-evolution > wrote: > > >> On Mar 20, 2017, at 8:07 PM, Greg Parker wrote: >> >> This needs more explanation. It is allowed for a subclass to implement a >> convenience

Re: [swift-evolution] [Proposal] Factory Initializers

> On Mar 20, 2017, at 8:07 PM, Greg Parker wrote: > > This needs more explanation. It is allowed for a subclass to implement a > convenience initializer that has the same signature as a superclass > convenience initializer or a superclass designated initializer. The >

Re: [swift-evolution] [Proposal] Factory Initializers

> Le 21 mars 2017 à 22:09, Jonathan Hull via swift-evolution > a écrit : > > There are several reasons. It is a very common pattern in ObjC/Cocoa. For > example, they allow class clusters (and the protocol equivalent). I don’t see that as a strong argument for

Re: [swift-evolution] [Proposal] Factory Initializers

There are several reasons. It is a very common pattern in ObjC/Cocoa. For example, they allow class clusters (and the protocol equivalent). One of the Apple foundation people replied earlier in this thread that it would allow them to remove several hacks from the foundation overlays, and

Re: [swift-evolution] [Proposal] Factory Initializers

This was kind of my point - all current class initializers are allocating. Allowing non-allocating initializers would solve most cases, including factory methods. The last else statement in your example (for a regular case) can definitely return a value from another initializer - e.g.

Re: [swift-evolution] [Proposal] Factory Initializers

I believe that this proposal is trying to solve something that can be solved by allowing assignment to self within convenience initializers. Unfortunately, even convenience initializers are allocating which makes it harder to achieve with backward compatibility - though I'm not entirely sure

Re: [swift-evolution] [Proposal] Factory Initializers

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

Re: [swift-evolution] [Proposal] Factory Initializers

I just have to ask: why should a factory method be part of the language? I have nothing against it, I am just wondering if I am missing something. The way I see it everyone can add a factory initializer if he/she needs it. Why make it part of the language? Regards, Rien Site:

Re: [swift-evolution] [Proposal] Factory Initializers

+ IntMax.max On Tue, Mar 21, 2017 at 12:07 PM, Greg Parker via swift-evolution < swift-evolution@swift.org> wrote: > > On Mar 17, 2017, at 9:26 AM, Riley Testut via swift-evolution < > swift-evolution@swift.org> wrote: > > Hi again everyone! > > Now that Swift 4 Stage 2 proposals are being

Re: [swift-evolution] [Proposal] Factory Initializers

> On Mar 17, 2017, at 9:26 AM, Riley Testut via swift-evolution > wrote: > > Hi again everyone! > > 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

Re: [swift-evolution] [Proposal] Factory Initializers

I'm in favor of this pattern. > On Mar 20, 2017, at 4:40 PM, Jonathan Hull via swift-evolution > wrote: > > Huge +1 > > >> On Mar 17, 2017, at 9:26 AM, Riley Testut via swift-evolution >> wrote: >> >> Hi again everyone! >> >> Now

Re: [swift-evolution] [Proposal] Factory Initializers

Huge +1 > On Mar 17, 2017, at 9:26 AM, Riley Testut via swift-evolution > wrote: > > Hi again everyone! > > 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

Re: [swift-evolution] [Proposal] Factory Initializers

> What's the motivation behind using `return` rather than self-assignment, like > we currently have in inits for structs/enums and protocol extensions? >From the original discussion, it seemed the general consensus was that >returning a value felt more natural than assigning to self. Here are

Re: [swift-evolution] [Proposal] Factory Initializers

Big +1. Two small nits/questions: - What's the motivation behind using `return` rather than self- assignment, like we currently have in inits for structs/enums and protocol extensions? I didn't follow the original discussion in depth, so excuse me if this has been hashed out before. -

Re: [swift-evolution] [Proposal] Factory Initializers

I am really glad to see this up again. It is definitely something that I am quite certain that all of the Foundation team and contriubters are quite enthusiastic about. I know it would likely mean some extra work for the compiler team but factory initializers would be quite impactful not only

Re: [swift-evolution] [Proposal] Factory Initializers

Hi again everyone! 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. As a quick tl;dr, this proposal describes a new "factory initializer" that would allow you to return

Re: [swift-evolution] [Proposal] Factory Initializers

i would appreciate this feature. 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

Re: [swift-evolution] [Proposal] Factory Initializers

Howdy, Yes, I would like a feature like this. I’m working on a number of apps where I have a number of concrete types which conform to a protocol. Deserializing means picking one, and I’d love to be able to declare a protocol-scoped method which can pick between different subclasses.

Re: [swift-evolution] [Proposal] Factory Initializers

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

Re: [swift-evolution] [Proposal] Factory Initializers

At first, I was opposed to this idea but after working with many heterogeneous implementations of the same protocol, where instance creation needs to be dynamically dispatched to based on the properties of the data, I think that factory initialisers might be a nice idea. However, it would IMO

Re: [swift-evolution] [Proposal] Factory Initializers

I thought this already went in review somehow, sorry a +1 from me as well. [[iOS messageWithData:ideas] broadcast] > On 10 Apr 2016, at 19:14, Radosław Pietruszewski via swift-evolution > wrote: > > Nice! > > I must admit, my first reaction to this proposal was

Re: [swift-evolution] [Proposal] Factory Initializers

+1 from me as well! > On Apr 9, 2016, at 12:17 PM, Riley Testut wrote: > > Hello again everyone! > > Just an update, I did submit the PR about a week ago, and you can check it > out here: > https://github.com/apple/swift-evolution/pull/247 >

Re: [swift-evolution] [Proposal] Factory Initializers

Nice! I must admit, my first reaction to this proposal was “uhhh, why complicate initializers even more?”. But then I hit these two roadblocks: 1. I wanted to add an initializer on `NSTimer` extension that returns the (toll-free-bridged) value from CFRunLoopTimerCreateWithHandler. Sadly, this

Re: [swift-evolution] [Proposal] Factory Initializers

Hey all! Just updated the proposal with all the recent changes, and you can check it here: https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md

Re: [swift-evolution] [Proposal] Factory Initializers

Yeah. I was thinking we would want to mirror the convenience initializer syntax, but I am completely ok with this as well. Honestly this is the syntax I first tried to use in convenience inits while learning swift, and I would love to see that migrate to something like this. My only worry

Re: [swift-evolution] [Proposal] Factory Initializers

If we are to enforce a different type signature for factory initializers vs required/convenience initializers (which would greatly simplify this issue), if I’m understanding correctly, there shouldn’t be a need to be able to “return” self.init(), right? Because you could do this instead:

Re: [swift-evolution] [Proposal] Factory Initializers

Ah, good catch. Would that be confusing as to whether self.init() would lead to an infinite loop, or call the required initializer? Unlike convenience initializers, factory initializers might have the same signature as the required ones. > On Mar 30, 2016, at 2:52 AM, Jonathan Hull

Re: [swift-evolution] [Proposal] Factory Initializers

Agreed. I would like to see what I was referring to as “stage 1” in this proposal, and we can (hopefully) add on a full solution over time. (I just wanted to make sure we considered those cases so we didn’t block future improvements) Looking at the proposal, my only contention would be that

Re: [swift-evolution] [Proposal] Factory Initializers

Ultimately, while these are good points, I feel the full mechanism for class clusters belong in a separate proposal. The focus for this one I believe should be the underlying mechanism of factory initializers; should that be approved, then we can focus on adding additional features on top of

Re: [swift-evolution] [Proposal] Factory Initializers

Comments inline. > On Mar 24, 2016, at 12:10 AM, Riley Testut wrote: > > While I do believe your proposed additions have their benefits, my gut tells > me this is too large a change to Swift for an arguably small gain. For this > proposal, I'm wanting to keep the change

Re: [swift-evolution] [Proposal] Factory Initializers

FWIW, even in Swift2, factory initializer is possible. I've post a gist here: https://gist.github.com/rintaro/9eadc2720ac8be6a7898 It's pretty hackish though :) 2016-03-22 15:16 GMT+09:00 Riley Testut via swift-evolution < swift-evolution@swift.org>: > Hey all! > > Very sorry, restored my

Re: [swift-evolution] [Proposal] Factory Initializers

While I do believe your proposed additions have their benefits, my gut tells me this is too large a change to Swift for an arguably small gain. For this proposal, I'm wanting to keep the change as minimalistic as possible, while still providing enough flexibility and use cases to warrant it.

Re: [swift-evolution] [Proposal] Factory Initializers

Yes and No. Yes, because this is a problem I run into all the time, and I really want swift to have a solution for it. I especially like Brent’s idea of a protocol init. No, because I have gotten a bit greedy. I want us to take a step back and look at the underlying problem to see if we can

Re: [swift-evolution] [Proposal] Factory Initializers

+1 for factory initializers on classes. -0.5 for factory initializers on protocols. I believe there is a strong pairing between Dependency Inversion (from SOLID principals, that you should depend on abstractions like protocols instead of concretions like a particular class) and dependency

Re: [swift-evolution] [Proposal] Factory Initializers

Definitely a +1 here on interest for this proposal, have run into this several times. On Tue, Mar 22, 2016 at 5:16 PM, Riley Testut via swift-evolution < swift-evolution@swift.org> wrote: > Hey all! > > Very sorry, restored my MacBook at the beginning of the calendar year, and > forgot to

Re: [swift-evolution] [Proposal] Factory Initializers

Hey all! Very sorry, restored my MacBook at the beginning of the calendar year, and forgot to re-subscribe to Swift-Evolution . Once I realized this, I decided to hold off on pushing this forward till after Swift 2.2, and now that it's been released, I'd love to make moves on this! So, is

Re: [swift-evolution] [Proposal] Factory Initializers

Glad to see there's definitely some interest in this community then! I would love to start writing up a final proposal to submit to the Swift-Evolution repo, but I think that last piece of information needed would be the actual method of initialization, specifically should we allow for

Re: [swift-evolution] [Proposal] Factory Initializers

> On Dec 18, 2015, at 8:15 AM, Thorsten Seitz wrote: > > Now I'm confused: I thought the idea should enable class clusters, i.e. > allowing AbstractBaseClass(42) to return something with the *dynamic* type of > ConcreteImplementation but still the static type of