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

[Erica Sadun via swift-evolution]

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  > wrote:
> 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 
> > wrote:
> Is this proposal in the pipeline for Swift 4?
> 
> On 1 April 2017 at 12:03, Adrian Zubarev via swift-evolution 
> > 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 
> 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 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 Self in Self, 
> which smells to me like really bad code.
> 
> MyCustomView // This view is useless
>+ MyCustomView
>+ CustomSubview1
>+ CustomSubview1 // This is probably a dead IBOutlet
> In fact Xcode does not use the initializer from NSCoding to show a live 
> rendered view inside interface builder, instead it will call a UIViews 
> designated initializer init(frame:). That results that a lot of the developer 
> write similar code like in the following snippet:
> 
> // This pattern results in a similar view cluster like mentioned above
> 
> class MyCustomView : UIView {
> override init(frame: CGRect) {
> let view = loadSomehowFromNib()
> self.addSubview(view)
> }
> }
> 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 
> factory.
> 
> Personally I would want to write something like this instead.
> 
> 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
> }
> }
> This should resolve the clustering issue by assigning the returned instance 
> from the function to self and create a correct view hierarchy.
> 
> + MyCustomView
>+ CustomSubview1
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 17. März 2017 um 17:26:29, Riley Testut via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> 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 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: 
>> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
>>  
>> 
>> 
>> 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!
>> 
>> Riley Testut
>> 
>> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian > > wrote:
>> 
>>> 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 thing to do.
>>> 
 On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution 
 > wrote:
 
 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.
 

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

[Xiaodi Wu via swift-evolution]

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 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 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
 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 Self in Self, which smells to me like really bad code.

 MyCustomView // This view is useless
+ MyCustomView
+ CustomSubview1
+ CustomSubview1 // This is probably a dead IBOutlet

 In fact Xcode does not use the initializer from NSCoding to show a
 live rendered view inside interface builder, instead it will call a UIViews
 designated initializer init(frame:). That results that a lot of the
 developer write similar code like in the following snippet:

 // This pattern results in a similar view cluster like mentioned above

 class MyCustomView : UIView {
 override init(frame: CGRect) {
 let view = loadSomehowFromNib()
 self.addSubview(view)
 }
 }

 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 factory.

 Personally I would want to write something like this instead.

 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
 }
 }

 This should resolve the clustering issue by assigning the returned
 instance from the function to self and create a correct view hierarchy.

 + MyCustomView
+ CustomSubview1



 --
 Adrian Zubarev
 Sent with Airmail

 Am 17. März 2017 um 17:26:29, Riley Testut via swift-evolution (
 swift-evolution@swift.org) schrieb:

 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 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:
 https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md

 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!

 Riley Testut

 On Nov 19, 2016, at 7:45 AM, arkadi daniyelian 
 wrote:

 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 thing to do.

 On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution <
 swift-evolution@swift.org> wrote:


 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.


 Charles


 On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution <
 swift-evolution@swift.org> wrote:


 Recently, I proposed the idea of adding the ability to implement the
 "class cluster" pattern from Cocoa (Touch) in Swift. However, as we
 discussed 

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

[Pranshu Goyal via swift-evolution]

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 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
>>> 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
>>> 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 Self in Self, which smells to me like really bad code.
>>>
>>> MyCustomView // This view is useless
>>>+ MyCustomView
>>>+ CustomSubview1
>>>+ CustomSubview1 // This is probably a dead IBOutlet
>>>
>>> In fact Xcode does not use the initializer from NSCoding to show a live
>>> rendered view inside interface builder, instead it will call a UIViews
>>> designated initializer init(frame:). That results that a lot of the
>>> developer write similar code like in the following snippet:
>>>
>>> // This pattern results in a similar view cluster like mentioned above
>>>
>>> class MyCustomView : UIView {
>>> override init(frame: CGRect) {
>>> let view = loadSomehowFromNib()
>>> self.addSubview(view)
>>> }
>>> }
>>>
>>> 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 factory.
>>>
>>> Personally I would want to write something like this instead.
>>>
>>> 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
>>> }
>>> }
>>>
>>> This should resolve the clustering issue by assigning the returned
>>> instance from the function to self and create a correct view hierarchy.
>>>
>>> + MyCustomView
>>>+ CustomSubview1
>>>
>>>
>>>
>>> --
>>> Adrian Zubarev
>>> Sent with Airmail
>>>
>>> Am 17. März 2017 um 17:26:29, Riley Testut via swift-evolution (
>>> swift-evolution@swift.org) schrieb:
>>>
>>> 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 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: https://github.com/rileytestut/swift-evolution/
>>> blob/master/proposals/-factory-initializers.md
>>>
>>> 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!
>>>
>>> Riley Testut
>>>
>>> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian 
>>> wrote:
>>>
>>> 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 thing to do.
>>>
>>> On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>>
>>> 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.
>>>
>>>
>>> Charles
>>>
>>>
>>> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>>
>>> 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:
>>>
>>>
>>> # Factory Initializers
>>>
>>>
>>> The "factory" 

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

[Xiaodi Wu via swift-evolution]

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 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
>> 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 Self in Self, which smells to me like really bad code.
>>
>> MyCustomView // This view is useless
>>+ MyCustomView
>>+ CustomSubview1
>>+ CustomSubview1 // This is probably a dead IBOutlet
>>
>> In fact Xcode does not use the initializer from NSCoding to show a live
>> rendered view inside interface builder, instead it will call a UIViews
>> designated initializer init(frame:). That results that a lot of the
>> developer write similar code like in the following snippet:
>>
>> // This pattern results in a similar view cluster like mentioned above
>>
>> class MyCustomView : UIView {
>> override init(frame: CGRect) {
>> let view = loadSomehowFromNib()
>> self.addSubview(view)
>> }
>> }
>>
>> 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 factory.
>>
>> Personally I would want to write something like this instead.
>>
>> 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
>> }
>> }
>>
>> This should resolve the clustering issue by assigning the returned
>> instance from the function to self and create a correct view hierarchy.
>>
>> + MyCustomView
>>+ CustomSubview1
>>
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 17. März 2017 um 17:26:29, Riley Testut via swift-evolution (
>> swift-evolution@swift.org) schrieb:
>>
>> 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 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:
>> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
>>
>> 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!
>>
>> Riley Testut
>>
>> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian  wrote:
>>
>> 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 thing to do.
>>
>> On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> 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.
>>
>>
>> Charles
>>
>>
>> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> 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:
>>
>>
>> # Factory Initializers
>>
>>
>> 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 

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

[Pranshu Goyal via swift-evolution]

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
> 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 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 Self in
> Self, which smells to me like really bad code.
>
> MyCustomView // This view is useless
>+ MyCustomView
>+ CustomSubview1
>+ CustomSubview1 // This is probably a dead IBOutlet
>
> In fact Xcode does not use the initializer from NSCoding to show a live
> rendered view inside interface builder, instead it will call a UIViews
> designated initializer init(frame:). That results that a lot of the
> developer write similar code like in the following snippet:
>
> // This pattern results in a similar view cluster like mentioned above
>
> class MyCustomView : UIView {
> override init(frame: CGRect) {
> let view = loadSomehowFromNib()
> self.addSubview(view)
> }
> }
>
> 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 factory.
>
> Personally I would want to write something like this instead.
>
> 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
> }
> }
>
> This should resolve the clustering issue by assigning the returned
> instance from the function to self and create a correct view hierarchy.
>
> + MyCustomView
>+ CustomSubview1
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 17. März 2017 um 17:26:29, Riley Testut via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> 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 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: https://github.com/rileytestut/swift-evolution/
> blob/master/proposals/-factory-initializers.md
>
> 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!
>
> Riley Testut
>
> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian  wrote:
>
> 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 thing to do.
>
> On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> 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.
>
>
> Charles
>
>
> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> 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:
>
>
> # Factory Initializers
>
>
> 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 

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

[Adrian Zubarev via swift-evolution]

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 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 Self in Self, which 
smells to me like really bad code.

MyCustomView // This view is useless
   + MyCustomView
   + CustomSubview1
   + CustomSubview1 // This is probably a dead IBOutlet
In fact Xcode does not use the initializer from NSCoding to show a live 
rendered view inside interface builder, instead it will call a UIViews 
designated initializer init(frame:). That results that a lot of the developer 
write similar code like in the following snippet:

// This pattern results in a similar view cluster like mentioned above

class MyCustomView : UIView {
override init(frame: CGRect) {
let view = loadSomehowFromNib()
self.addSubview(view)
}
}
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 
factory.

Personally I would want to write something like this instead.

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
}
}
This should resolve the clustering issue by assigning the returned instance 
from the function to self and create a correct view hierarchy.

+ MyCustomView
   + CustomSubview1


-- 
Adrian Zubarev
Sent with Airmail

Am 17. März 2017 um 17:26:29, Riley Testut via swift-evolution 
(swift-evolution@swift.org) schrieb:

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 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: 
https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md

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!

Riley Testut

On Nov 19, 2016, at 7:45 AM, arkadi daniyelian  wrote:

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 thing to do.

On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution 
 wrote:

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.

Charles

On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
 wrote:

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:

# Factory Initializers

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.

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 

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

[Rien via swift-evolution]

> 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 same signature as a superclass 
>> convenience initializer or a superclass designated initializer. The 
>> convenience-over-convenience case is not technically overriding, but it is 
>> misleading to say only that a convenience initializer cannot be overridden. 
>> Do factory initializers follow exactly the same rules here as convenience 
>> initializers?
> 
> Yes, that is what I meant. For simplicity, I think the factory initializer 
> inheritance rules should match exactly that of convenience initializers.
> 
>> In addition: designated initializers and convenience initializers have rules 
>> about which other initializers can be called from an implementation. These 
>> rules are intended to guarantee that the chain of designated initializers is 
>> called correctly. What are the precise rules for factory initializers 
>> calling other initializers? What are the precise rules for non-factory 
>> initializers calling factory initializers?
> 
> Factory initializers can call any other initializers. Since calling 
> convenience initializers would still call required initializers, the chain 
> would be correct (unless I’m missing something). As for other initializers 
> calling factory initializers, my gut says this should not be allowed. Factory 
> initializers are supposed to initialize and return a value, whereas other 
> initializers implicitly assign to self. Therefore calling a factory 
> initializer from a self-assigning initializer wouldn’t do much, and I don’t 
> see any benefit to allowing this.
> 
> 
>> On Mar 21, 2017, at 8:49 AM, David Rönnqvist  
>> wrote:
>> 
>> 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.
> 
> I can answer this anecdotally; when learning iOS development and Objective-C, 
> it was (in my opinion) hard to know whether an Objective-C class was meant to 
> be initialized via [[Class alloc] initWithParameters:] or [Class 
> classWithParameters:]. Pre-ARC this did actually have meaning, but post 
> ARC/iOS 5 it just seemed to be whatever the framework developer preferred 
> (not to mention that [Class new] was also another option…).
> 
> When Swift combined all these forms into one common Class(parameters:) 
> format, this greatly reduced this cognitive load. However, as outlined in the 
> proposal, this meant that the factory pattern had to be moved out of the 
> initializers and back into class methods. Because of this, now if you want to 
> implement the factory pattern, you’re bringing back this same confusion from 
> Objective-C; the client has to remember whether your class is initialized via 
> standard Class(parameters:) syntax, or by calling a class method 
> Class.classWithParameters(). Ultimately, I don’t believe there should be a 
> difference between the two for the average programmer. You want an instance 
> of the class, so you should retrieve one by calling an initializer. They 
> don’t need to know or care whether the initializer is directly assigning to 
> self or returning a value, as long as they get the value they need.

If we want to hide the fact that a factory method is a factory method, then we 
need the “assign to self’ in the initializer. Introducing a ‘factory’ keyword 
for that purpose seem counter productive to me.

Rien.

> 
> Beyond this, however, I think the factory initializers on protocols is one of 
> this proposal’s biggest wins. For protocol oriented programming, it’s nice to 
> be apply to supply a default implementation so client’s don’t need to declare 
> their own type. However, if you come across a new codebase/framework, you 
> might not know the difference between the specific type you’re using and the 
> protocol itself (or even which one is which). I’ve personally encountered 
> this many times with Apple’s frameworks, such as UIActivityItemProvider and 
> UIActivityItemSource (which one is the protocol and which one is the type? 
> Hard to know and remember when first using them). With factory initializers 
> on protocol extensions, the initializer can return a private type conforming 
> to the protocol, so again there’s no need to worry about what is the concrete 
> type and what is the protocol.
> 
> P.S. Phase 2 End Question
> 
> I didn’t realize until today that apparently Swift 4 Phase 2 ends tomorrow. 
> Is this true, and does that mean this is now too late to make it into Swift 4?
> 

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

[Goffredo Marocchi via swift-evolution]

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 initializer that has the same signature as a superclass 
>> convenience initializer or a superclass designated initializer. The 
>> convenience-over-convenience case is not technically overriding, but it is 
>> misleading to say only that a convenience initializer cannot be overridden. 
>> Do factory initializers follow exactly the same rules here as convenience 
>> initializers?
> 
> Yes, that is what I meant. For simplicity, I think the factory initializer 
> inheritance rules should match exactly that of convenience initializers.
> 
>> In addition: designated initializers and convenience initializers have rules 
>> about which other initializers can be called from an implementation. These 
>> rules are intended to guarantee that the chain of designated initializers is 
>> called correctly. What are the precise rules for factory initializers 
>> calling other initializers? What are the precise rules for non-factory 
>> initializers calling factory initializers?
> 
> Factory initializers can call any other initializers. Since calling 
> convenience initializers would still call required initializers, the chain 
> would be correct (unless I’m missing something). As for other initializers 
> calling factory initializers, my gut says this should not be allowed. Factory 
> initializers are supposed to initialize and return a value, whereas other 
> initializers implicitly assign to self. Therefore calling a factory 
> initializer from a self-assigning initializer wouldn’t do much, and I don’t 
> see any benefit to allowing this.
> 
> 
>> On Mar 21, 2017, at 8:49 AM, David Rönnqvist  
>> wrote:
>> 
>> 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.
> 
> I can answer this anecdotally; when learning iOS development and Objective-C, 
> it was (in my opinion) hard to know whether an Objective-C class was meant to 
> be initialized via [[Class alloc] initWithParameters:] or [Class 
> classWithParameters:]. Pre-ARC this did actually have meaning, but post 
> ARC/iOS 5 it just seemed to be whatever the framework developer preferred 
> (not to mention that [Class new] was also another option…).
> 
> When Swift combined all these forms into one common Class(parameters:) 
> format, this greatly reduced this cognitive load. However, as outlined in the 
> proposal, this meant that the factory pattern had to be moved out of the 
> initializers and back into class methods. Because of this, now if you want to 
> implement the factory pattern, you’re bringing back this same confusion from 
> Objective-C; the client has to remember whether your class is initialized via 
> standard Class(parameters:) syntax, or by calling a class method 
> Class.classWithParameters(). Ultimately, I don’t believe there should be a 
> difference between the two for the average programmer. You want an instance 
> of the class, so you should retrieve one by calling an initializer. They 
> don’t need to know or care whether the initializer is directly assigning to 
> self or returning a value, as long as they get the value they need.
> 
> Beyond this, however, I think the factory initializers on protocols is one of 
> this proposal’s biggest wins. For protocol oriented programming, it’s nice to 
> be apply to supply a default implementation so client’s don’t need to declare 
> their own type. However, if you come across a new codebase/framework, you 
> might not know the difference between the specific type you’re using and the 
> protocol itself (or even which one is which). I’ve personally encountered 
> this many times with Apple’s frameworks, such as UIActivityItemProvider and 
> UIActivityItemSource (which one is the protocol and which one is the type? 
> Hard to know and remember when first using them). With factory initializers 
> on protocol extensions, the initializer can return a private type conforming 
> to the protocol, so again there’s no need to worry about what is the concrete 
> type and what is the protocol.
> 
> P.S. Phase 2 End Question
> 
> I didn’t realize until today that apparently Swift 4 Phase 2 ends tomorrow. 
> Is this true, and does that mean this is now too late to make it into Swift 4?

Did not realise it either... does this mean that we are not getting argument 
labels in closures passed to functions back as it was promised last year? :(

> ___
> swift-evolution 

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

[Riley Testut via swift-evolution]

> 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 
> convenience-over-convenience case is not technically overriding, but it is 
> misleading to say only that a convenience initializer cannot be overridden. 
> Do factory initializers follow exactly the same rules here as convenience 
> initializers?

Yes, that is what I meant. For simplicity, I think the factory initializer 
inheritance rules should match exactly that of convenience initializers.

> In addition: designated initializers and convenience initializers have rules 
> about which other initializers can be called from an implementation. These 
> rules are intended to guarantee that the chain of designated initializers is 
> called correctly. What are the precise rules for factory initializers calling 
> other initializers? What are the precise rules for non-factory initializers 
> calling factory initializers?

Factory initializers can call any other initializers. Since calling convenience 
initializers would still call required initializers, the chain would be correct 
(unless I’m missing something). As for other initializers calling factory 
initializers, my gut says this should not be allowed. Factory initializers are 
supposed to initialize and return a value, whereas other initializers 
implicitly assign to self. Therefore calling a factory initializer from a 
self-assigning initializer wouldn’t do much, and I don’t see any benefit to 
allowing this.


> On Mar 21, 2017, at 8:49 AM, David Rönnqvist  
> wrote:
> 
> 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.

I can answer this anecdotally; when learning iOS development and Objective-C, 
it was (in my opinion) hard to know whether an Objective-C class was meant to 
be initialized via [[Class alloc] initWithParameters:] or [Class 
classWithParameters:]. Pre-ARC this did actually have meaning, but post ARC/iOS 
5 it just seemed to be whatever the framework developer preferred (not to 
mention that [Class new] was also another option…).

When Swift combined all these forms into one common Class(parameters:) format, 
this greatly reduced this cognitive load. However, as outlined in the proposal, 
this meant that the factory pattern had to be moved out of the initializers and 
back into class methods. Because of this, now if you want to implement the 
factory pattern, you’re bringing back this same confusion from Objective-C; the 
client has to remember whether your class is initialized via standard 
Class(parameters:) syntax, or by calling a class method 
Class.classWithParameters(). Ultimately, I don’t believe there should be a 
difference between the two for the average programmer. You want an instance of 
the class, so you should retrieve one by calling an initializer. They don’t 
need to know or care whether the initializer is directly assigning to self or 
returning a value, as long as they get the value they need.

Beyond this, however, I think the factory initializers on protocols is one of 
this proposal’s biggest wins. For protocol oriented programming, it’s nice to 
be apply to supply a default implementation so client’s don’t need to declare 
their own type. However, if you come across a new codebase/framework, you might 
not know the difference between the specific type you’re using and the protocol 
itself (or even which one is which). I’ve personally encountered this many 
times with Apple’s frameworks, such as UIActivityItemProvider and 
UIActivityItemSource (which one is the protocol and which one is the type? Hard 
to know and remember when first using them). With factory initializers on 
protocol extensions, the initializer can return a private type conforming to 
the protocol, so again there’s no need to worry about what is the concrete type 
and what is the protocol.

P.S. Phase 2 End Question

I didn’t realize until today that apparently Swift 4 Phase 2 ends tomorrow. Is 
this true, and does that mean this is now too late to make it into Swift 4?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jean-Daniel via swift-evolution]

> 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 factory initializers.
The only benefit from factory initializer vs the convenient initializers in 
Obj-C is that they avoid an autorelease access. Now that ARC let us bypass the 
autorelease pool completely for such call, they are not needed anymore and 
implementing a factory initializer using a class method is far less error prone.

> 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 
> improve safety.
> 
> One of the ideas I am most excited about is the ability for a protocol to 
> provide default conformances.  For example, I have an Expression protocol to 
> represent mathematical expressions, and I have a few basic conforming structs 
> representing constants, variables, and some basic operations.  With a factory 
> method, I can say ‘Expression(2)’ or ‘Expression(“VarName”)’ and have it 
> create the correct conformance.  My conforming structs can even be private, 
> if I want this to be the only way they are created.
> 
> If I have expensive-to-create immutable objects where I am creating 
> equivalent values all the time, I can store commonly created values in a 
> cache and return the cached versions (instead of creating an instance).  I 
> believe cocoa used to do this with NSNumbers before tagged pointers became a 
> thing.
> 
> Or, I could return something which is lazily created.
> 
> Longer term (once reflection has improved), I have a proposal to allow 
> extensible factory methods. We talked about it during the original 
> discussion, but the gist is that there would be way to get a list of all 
> types conforming to a protocol (or all subclasses of a class) from the 
> compiler, and then you could use static methods to query those types until 
> you found one which has the properties you are looking for, and then 
> instantiate and return it.  The end result is that you have a factory 
> initializer where new conformances (even from plug-ins) can participate and 
> be returned when appropriate.  This proposal is a necessary first step to 
> that.
> 
> As a concrete use-case of that extension, I have been experimenting for years 
> with auto-creating UI to edit structured data (e.g. JSON or Plists) or 
> objects.  This is fairly easy in ObjC, but it is only possible in Swift in a 
> very limited way at the moment.  With the above extension and key paths, I 
> should be able to recreate my ObjC interfaces in a nicer/swiftier way.
> 
> Those are just a few of the uses.
> 

All your point are valid use cases, but they don’t tell us why is it better to 
support them using a language specific construct vs using a class method (and 
make the designated constructor private if you want to force all user of your 
class to use your factory method).

Or maybe I’m missing something ?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jonathan Hull via swift-evolution]

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 improve 
safety.

One of the ideas I am most excited about is the ability for a protocol to 
provide default conformances.  For example, I have an Expression protocol to 
represent mathematical expressions, and I have a few basic conforming structs 
representing constants, variables, and some basic operations.  With a factory 
method, I can say ‘Expression(2)’ or ‘Expression(“VarName”)’ and have it create 
the correct conformance.  My conforming structs can even be private, if I want 
this to be the only way they are created.

If I have expensive-to-create immutable objects where I am creating equivalent 
values all the time, I can store commonly created values in a cache and return 
the cached versions (instead of creating an instance).  I believe cocoa used to 
do this with NSNumbers before tagged pointers became a thing.

Or, I could return something which is lazily created.

Longer term (once reflection has improved), I have a proposal to allow 
extensible factory methods. We talked about it during the original discussion, 
but the gist is that there would be way to get a list of all types conforming 
to a protocol (or all subclasses of a class) from the compiler, and then you 
could use static methods to query those types until you found one which has the 
properties you are looking for, and then instantiate and return it.  The end 
result is that you have a factory initializer where new conformances (even from 
plug-ins) can participate and be returned when appropriate.  This proposal is a 
necessary first step to that.

As a concrete use-case of that extension, I have been experimenting for years 
with auto-creating UI to edit structured data (e.g. JSON or Plists) or objects. 
 This is fairly easy in ObjC, but it is only possible in Swift in a very 
limited way at the moment.  With the above extension and key paths, I should be 
able to recreate my ObjC interfaces in a nicer/swiftier way.

Those are just a few of the uses.

Thanks,
Jon

> On Mar 21, 2017, at 8:49 AM, David Rönnqvist via swift-evolution 
>  wrote:
> 
> 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.
> 
> 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. 
>  
> Regards,
> David
> 
> 
>> On 17 Mar 2017, at 17:26, 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 for Swift 4.
>> 
>> 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: 
>> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
>>  
>> 
>> 
>> 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!
>> 
>> Riley Testut
>> 
>> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian > > wrote:
>> 
>>> 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 thing to do.
>>> 
 On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution 
 > wrote:
 
 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.
 
 Charles
 
> On Dec 17, 2015, at 3:41 PM, Riley Testut via 

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

[Charlie Monroe via swift-evolution]

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. init(reservingCapacity:).

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.

The same way, you could assign to self and then access instance variables 
within self.

Taking your example, all returns would be assignment to self and the last 
branch of the if-else statement would read as follows:

self = self.init(reservingCapacity: cnt)
for idx in 0.. On Mar 21, 2017, at 6:04 PM, Philippe Hausler  wrote:
> 
> One concept to consider here is that the initializers that are factories may 
> or may not replace self;
> 
> Take for example NSArray (inspired from the objective-c implementation but 
> written in swift, but note this is not the only use case)
> 
> public init(objects: UnsafePointer!, count cnt: Int) {
> if count == 0 && type(of: self) == NSArray.self {
> // specialized NSArray that does not contain any objects; it is a 
> singleton so we dont need to allocate at all
> return __NSArray0.zeroElementSingleton
> } else if count == 1 type(of: self) == NSArray.self {
> // The single object version is more effecient since it does not need 
> to indirect to a buffer
> return __NSArray1(objects.pointee)
> } else if type(of: self) == NSArray.self {
> return CFArrayCreate(kCFAllocatorSystemDefault, 
> UnsafeMutablePointer(objects), cnt, )
> } else {
> _storage.reserveCapacity(cnt)
> for idx in 0.. _storage.append(objects[idx])
> }
> }
> }
> 
> 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.
> 
>> On Mar 21, 2017, at 4:28 PM, Charlie Monroe via swift-evolution 
>> > wrote:
>> 
>> 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 
>> what would be the consequences of turning them into non-allocating.
>> 
>> 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:
>> 
>> @nonallocating init(x: Int) {
>>  if x < 0 {
>>  self = NegativeMe(x: x)
>>  } else {
>>  self = PositiveMe(x: x)
>>  }
>> }
>> 
>> Which is pretty much what the proposal is suggesting, but removes the 
>> "factory" keyword which may be a bit misleading or narrowly named.
>> 
>> 
>>> On Mar 21, 2017, at 4:49 PM, David Rönnqvist via swift-evolution 
>>> > wrote:
>>> 
>>> 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.
>>> 
>>> 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. 
>>>  
>>> Regards,
>>> David
>>> 
>>> 
 On 17 Mar 2017, at 17:26, 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 for Swift 4.
 
 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: 
 https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
  
 

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

[Charlie Monroe via swift-evolution]

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 
what would be the consequences of turning them into non-allocating.

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:

@nonallocating init(x: Int) {
if x < 0 {
self = NegativeMe(x: x)
} else {
self = PositiveMe(x: x)
}
}

Which is pretty much what the proposal is suggesting, but removes the "factory" 
keyword which may be a bit misleading or narrowly named.


> On Mar 21, 2017, at 4:49 PM, David Rönnqvist via swift-evolution 
>  wrote:
> 
> 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.
> 
> 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. 
>  
> Regards,
> David
> 
> 
>> On 17 Mar 2017, at 17:26, 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 for Swift 4.
>> 
>> 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: 
>> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
>>  
>> 
>> 
>> 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!
>> 
>> Riley Testut
>> 
>> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian > > wrote:
>> 
>>> 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 thing to do.
>>> 
 On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution 
 > wrote:
 
 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.
 
 Charles
 
> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
> > wrote:
> 
> 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:
> 
> # Factory Initializers
> 
> 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.
> 
> Rather than have a separate factory method, I propose we build the 
> factory pattern right into Swift, by way of 

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

[David Rönnqvist via swift-evolution]

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.

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. 
 
Regards,
David


> On 17 Mar 2017, at 17:26, 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 for Swift 4.
> 
> 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: 
> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
>  
> 
> 
> 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!
> 
> Riley Testut
> 
> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian  > wrote:
> 
>> 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 thing to do.
>> 
>>> On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution 
>>> > wrote:
>>> 
>>> 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.
>>> 
>>> Charles
>>> 
 On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
 > wrote:
 
 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:
 
 # Factory Initializers
 
 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.
 
 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:
 
 class AbstractBase {
  public factory init(type: InformationToSwitchOn) {
  return ConcreteImplementation(type)
  }
 }
 
 class ConcreteImplementation : AbstractBase {
 
 }
 
 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:
 
 ## Class Cluster/Abstract Classes
 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.
 
 ## Protocol Initializers
 Proposed by Brent Royal-Gordon, we could use factory 

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

[Rien via swift-evolution]

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: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 20 Mar 2017, at 21:40, 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 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 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: 
>> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
>> 
>> 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!
>> 
>> Riley Testut
>> 
>> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian  wrote:
>> 
>>> 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 thing to do.
>>> 
 On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution 
  wrote:
 
 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.
 
 Charles
 
> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
>  wrote:
> 
> 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:
> 
> # Factory Initializers
> 
> 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.
> 
> 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:
> 
> class AbstractBase {
>  public factory init(type: InformationToSwitchOn) {
>  return ConcreteImplementation(type)
>  }
> }
> 
> class ConcreteImplementation : AbstractBase {
> 
> }
> 
> 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:
> 
> ## Class Cluster/Abstract Classes
> 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.
> 
> ## Protocol Initializers
> Proposed by Brent Royal-Gordon, we could use factory initializers with 
> protocol extensions to return the appropriate instance 

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

[Nicholas Maccharoli via swift-evolution]

+ 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 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 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: https://github.com/rileytestut/swift-evolution/
> blob/master/proposals/-factory-initializers.md
>
> 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!
>
>
> "As for overriding, just like convenience initializers, factory
> initializers should not be able to be overridden by subclasses."
>
> 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
> convenience-over-convenience case is not technically overriding, but it is
> misleading to say only that a convenience initializer cannot be overridden.
> Do factory initializers follow exactly the same rules here as convenience
> initializers?
>
> In addition: designated initializers and convenience initializers have
> rules about which other initializers can be called from an implementation.
> These rules are intended to guarantee that the chain of designated
> initializers is called correctly. What are the precise rules for factory
> initializers calling other initializers? What are the precise rules for
> non-factory initializers calling factory initializers?
>
>
> --
> Greg Parker gpar...@apple.com Runtime Wrangler
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Greg Parker via swift-evolution]

> 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 for Swift 4.
> 
> 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: 
> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
>  
> 
> 
> 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!

"As for overriding, just like convenience initializers, factory initializers 
should not be able to be overridden by subclasses."

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 
convenience-over-convenience case is not technically overriding, but it is 
misleading to say only that a convenience initializer cannot be overridden. Do 
factory initializers follow exactly the same rules here as convenience 
initializers?

In addition: designated initializers and convenience initializers have rules 
about which other initializers can be called from an implementation. These 
rules are intended to guarantee that the chain of designated initializers is 
called correctly. What are the precise rules for factory initializers calling 
other initializers? What are the precise rules for non-factory initializers 
calling factory initializers?


-- 
Greg Parker gpar...@apple.com Runtime Wrangler


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

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 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 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: 
>> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
>> 
>> 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!
>> 
>> Riley Testut
>> 
>>> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian  wrote:
>>> 
>>> 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 thing to do.
>>> 
 On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution 
  wrote:
 
 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.
 
 Charles
 
> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
>  wrote:
> 
> 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:
> 
> # Factory Initializers
> 
> 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.
> 
> 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:
> 
> class AbstractBase {
>  public factory init(type: InformationToSwitchOn) {
>  return ConcreteImplementation(type)
>  }
> }
> 
> class ConcreteImplementation : AbstractBase {
> 
> }
> 
> 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:
> 
> ## Class Cluster/Abstract Classes
> 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.
> 
> ## Protocol Initializers
> 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.
> 
> ## Initializing Storyboard-backed View Controller
> This is 

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

[Jonathan Hull via swift-evolution]

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 
> forth for Swift 4.
> 
> 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: 
> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
>  
> 
> 
> 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!
> 
> Riley Testut
> 
> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian  > wrote:
> 
>> 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 thing to do.
>> 
>>> On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution 
>>> > wrote:
>>> 
>>> 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.
>>> 
>>> Charles
>>> 
 On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
 > wrote:
 
 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:
 
 # Factory Initializers
 
 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.
 
 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:
 
 class AbstractBase {
  public factory init(type: InformationToSwitchOn) {
  return ConcreteImplementation(type)
  }
 }
 
 class ConcreteImplementation : AbstractBase {
 
 }
 
 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:
 
 ## Class Cluster/Abstract Classes
 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.
 
 ## Protocol Initializers
 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.
 
 ## Initializing Storyboard-backed View Controller
 This is more specific to Apple Frameworks, but having 

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

[Riley Testut via swift-evolution]

> 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 some 
>snippets from the original discussion:

Myself:
> I’m not opposed to assigning to self directly in convenience initializers 
> (especially if there is already support for it in the ABI). My only concern 
> would be that it feels less “natural” to do so than to simply return a value 
> from the initializer. That being said, I think that’s a very negligible 
> disadvantage (if even that), and if assigning to self is the easiest way to 
> pull this off, I’m all for it.


Dave Abrahams:
> My instinct agrees with that.  Also, reassigning self raises the question of 
> whether an object is allocated (and partly initialized?) before the 
> reassignment.  Even if we can answer those questions in some clear way, I’d 
> rather not have them come up at all.


Stephen Christopher:
> I agree. Were I to naively try this in Swift, I would expect to use a 
> convenience initializer and return the instance I’d created. 

Ultimately I'm happy with either returning a value or assigning to self, 
depending on what the consensus is after a review.

> Is the "factory" keyword truly necessary, or could it be implied by 
> "required" and using self-assignment in the init body?

Factory initializers would be closer to convenience initializers rather than 
required ones, and I think the keyword is semantically useful. 
Convenience/required initializers are expected to return a type matching that 
of the static type, while the "factory" keyword signifies that the return value 
may not match, just be upperbounded by the static type.

Additionally, when dealing with factory initializers in protocol extensions, I 
think it is much more clear in intent that the function will return a type that 
conforms to the protocol rather than a hypothetical "instance" of the protocol 
itself.

> On Mar 17, 2017, at 1:15 PM, Zach Waldowski via swift-evolution 
>  wrote:
> 
> 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.
> - Is the "factory" keyword truly necessary, or could it be implied by 
> "required" and using self-assignment in the init body?
> 
> Best,
>   Zachary Waldowski
>   z...@waldowski.me
> 
> 
>> On Fri, Mar 17, 2017, at 12:26 PM, 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 for Swift 4.
>> 
>> 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: 
>> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
>> 
>> 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!
>> 
>> Riley Testut
>> 
>>> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian  wrote:
>>> 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 thing to do.
>>> 
 On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution 
  wrote:
 
 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.
 
 Charles
 
> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
>  wrote:
> 
> 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 
> 

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

[Zach Waldowski via swift-evolution]

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.
- Is the "factory" keyword truly necessary, or could it be implied by
  "required" and using self-assignment in the init body?


Best,

  Zachary Waldowski

  z...@waldowski.me





On Fri, Mar 17, 2017, at 12:26 PM, 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 for Swift 4.
> 

> 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:
> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
> 

> 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!
> 

> Riley Testut

> 

> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian
>  wrote:
>> 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
>> thing to do.
>>
>>> On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution >> evolut...@swift.org> wrote:
>>>
>>> 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.
>>>
>>> Charles
>>>
 On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution >>> evolut...@swift.org> wrote:

 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:

 # Factory Initializers

 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.

 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:

 class AbstractBase { public factory init(type:
 InformationToSwitchOn) { return
 ConcreteImplementation(type) } }

 class ConcreteImplementation : AbstractBase {

 }

 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:

 ## Class Cluster/Abstract Classes
 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.

 ## Protocol Initializers
 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 

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

[Philippe Hausler via swift-evolution]

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 for correctness for implementing 
swift-corelibs-foundation, performance for a number of cases as well as safety 
(I am certain we could remove some gnarly hacks in both the Foundation overlay 
and swift-corelibs-foundation if we could utilize factory pattern initializers)

> On Mar 17, 2017, at 4:26 PM, 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 for Swift 4.
> 
> 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: 
> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
>  
> 
> 
> 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!
> 
> Riley Testut
> 
> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian  > wrote:
> 
>> 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 thing to do.
>> 
>>> On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution 
>>> > wrote:
>>> 
>>> 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.
>>> 
>>> Charles
>>> 
 On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
 > wrote:
 
 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:
 
 # Factory Initializers
 
 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.
 
 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:
 
 class AbstractBase {
  public factory init(type: InformationToSwitchOn) {
  return ConcreteImplementation(type)
  }
 }
 
 class ConcreteImplementation : AbstractBase {
 
 }
 
 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:
 
 ## Class Cluster/Abstract Classes
 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.
 
 ## Protocol 

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

[Riley Testut via swift-evolution]

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 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: 
https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md

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!

Riley Testut

> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian  wrote:
> 
> 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 thing to do.
> 
>> On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution 
>>  wrote:
>> 
>> 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.
>> 
>> Charles
>> 
>>> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
>>>  wrote:
>>> 
>>> 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:
>>> 
>>> # Factory Initializers
>>> 
>>> 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.
>>> 
>>> 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:
>>> 
>>> class AbstractBase {
>>>  public factory init(type: InformationToSwitchOn) {
>>>  return ConcreteImplementation(type)
>>>  }
>>> }
>>> 
>>> class ConcreteImplementation : AbstractBase {
>>> 
>>> }
>>> 
>>> 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:
>>> 
>>> ## Class Cluster/Abstract Classes
>>> 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.
>>> 
>>> ## Protocol Initializers
>>> 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.
>>> 
>>> ## Initializing Storyboard-backed View Controller
>>> 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 

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

[arkadi daniyelian via swift-evolution]

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 thing to do.

> On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution 
>  wrote:
> 
> 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.
> 
> Charles
> 
>> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
>>  wrote:
>> 
>> 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:
>> 
>> # Factory Initializers
>> 
>> 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.
>> 
>> 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:
>> 
>> class AbstractBase {
>>   public factory init(type: InformationToSwitchOn) {
>>   return ConcreteImplementation(type)
>>   }
>> }
>> 
>> class ConcreteImplementation : AbstractBase {
>> 
>> }
>> 
>> 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:
>> 
>> ## Class Cluster/Abstract Classes
>> 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.
>> 
>> ## Protocol Initializers
>> 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.
>> 
>> ## Initializing Storyboard-backed View Controller
>> 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.
>> 
>> Here are some comments from the previous thread that I believe are still 
>> relevant:
>> 
>> 
>>> On Dec 9, 2015, at 1:06 PM, Philippe Hausler  wrote:
>>> 
>>> 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.
>> 
>> 
>>> On Dec 7, 2015, at 5:24 PM, Brent Royal-Gordon  
>>> wrote:
>>> 
>>> A 

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

[Benjamin Spratling via swift-evolution]

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.  In some 
cases, I implement these as enums, but that unfortunately puts together a lot 
of code that I’d rather have apart.

My question is why bother writing “init” if I’ve already written “factory”?  It 
isn’t really an initializing anything, it’s actually delegating.  It really is 
just a static method, but a commonly-named and syntactically convenient way for 
someone to not know -or not need to know- that they are actually creating a 
subtype.

At that point, given that many of these are protocol-centric, what I want from 
a language standpoint is a way to define a protocol-scoped method.  In contrast 
to a static method, which can only be called from a concrete type which 
conforms to the protocol, in initializing the correct sub-type, we do not yet 
know the correct sub-type.

For instance, consider a presentation app which contains an array of user 
“entries”, which can be text, images, whatever.

protocol PresentationEntry {
}
extension PresentationEntry
protocol func new(json:[String:Any])throws-> PresentationEntry {
//…
if whatever {
return TextEntry(…
else {
return ImageEntry(...
}
}
struct TextEntry : PresentationEntry {
}
struct ImageEntry : PresentationEntry {
}

class Presentation {
var entries:[PresentationEntry]
init(json:[String:Any])throws {
//…
self.entries = entriesJson.flatMap(){ (json)-> 
PresentationEntry? in
return try? PresentationEntry.new(json:json)
}

Right now, I think I’m stuck tacking the creation method on somewhere, like as 
an instance method on the Presentation type, as a global function, or creating 
a type to do nothing but be the factory.

At that point, the question revolves around extensibility.  What if a sub-class 
adds another conforming type of concrete subclass?  That’s what protocols and 
classes are for, after all!  How do I modify the protocol’s protocol-scoped 
method to be overridden?  Using custom factory types,

i.e.
protocol PresentationEntryFactory : class {
weak var presentationFactory: PresentationFactory? { get set }
func new(json:[String:Any], 
factory:PresentationEntryFactory)throws->PresentationEntry {
...
}
}
class GenericPresentationEntryFactory : PresentationEntryFactory {
func new(json:[String:Any])throws->PresentationEntry {
if whatever {
return TextEntry(json:…, factory:Self)
else {
return ImageEntry(json:…, factory:Self)
}
...
}



I don’t have that problem. I just create my own factory type, using exactly the 
same interface:


struct SongEntry : PresentationEntry {
...
}
class SongCapablePresentationEntryFactory : PresentationEntryFactory {
func new(json:[String:Any])throw->PresentationEntry {
if whatever {
return TextEntry(json:…, factory:self)
else if whenever {
return ImageEntry(json:…, factory:self)
else {
return SongEntry(json:…, factory:self)
}
}

And now Presentation just gets its “entryFactory” from its factory and creates 
the entries.

Or perhaps the PresentationFactory creates the entries before it even creates 
the presentation and there never was a init(json:…  method on the Presentation 
in the first place.  But I get that one goal is to avoid the need to create all 
these additional factory classes.  A lot of developers would prefer to simply 
use an init( and never write them out.

So that’s a ‘general’ way to solve the problem now.  I’m not 100% sure that we 
have to have extensibility of these factory or protocol-scoped methods to 
proceed, but it would be nice to see what could happen with extensiblility with 
some more minds checking on this list.  Maybe a type “registration” method?  We 
could create a “factory register” keyword which tells the compiler to place the 
given type in a special run-time accessible location including a reference to 
the concrete type and a validation function.  Unfortunately, the validation 

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

[Charles Srstka via swift-evolution]

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.

Charles

> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
>  wrote:
> 
> 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:
> 
> # Factory Initializers
> 
> 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.
> 
> 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:
> 
> class AbstractBase {
>public factory init(type: InformationToSwitchOn) {
>return ConcreteImplementation(type)
>}
> }
> 
> class ConcreteImplementation : AbstractBase {
> 
> }
> 
> 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:
> 
> ## Class Cluster/Abstract Classes
> 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.
> 
> ## Protocol Initializers
> 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.
> 
> ## Initializing Storyboard-backed View Controller
> 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.
> 
> Here are some comments from the previous thread that I believe are still 
> relevant:
> 
> 
>> On Dec 9, 2015, at 1:06 PM, Philippe Hausler  wrote:
>> 
>> 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. 
> 
> 
>> On Dec 7, 2015, at 5:24 PM, Brent Royal-Gordon  
>> wrote:
>> 
>> 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.
>> 
>> Unlike other initializers, Swift usually won’t be 

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

[Taras Zakharko via swift-evolution]

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 make sense to 
restrict them to protocol extensions only.

— Taras


> On 11 Apr 2016, at 08:55, Goffredo Marocchi via swift-evolution 
>  wrote:
> 
> 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 “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 
>> is impossible, and so I have to write NSTimer.new(…) 
>> 
>>  :(
>> 2. I wanted to add a custom initializer to a class inheriting from UIButton. 
>> But I can’t, because the initializer for UIButton is `convenience init(type 
>> buttonType: UIButtonType)` :(
>> 
>> A `factory init` allowing me to use both the initializer syntax and return 
>> an object from some other initializer would solve both problems. The 
>> "Initializing Storyboard-backed View Controller” use case is also compelling 
>> to me.
>> 
>> +1.
>> 
>> — Radek
>> 
>>> On 09 Apr 2016, at 21:17, Riley Testut via swift-evolution 
>>> > 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 
>>> 
>>> 
>>> As far as I know, now we wait until a core team member reviews the PR, and 
>>> either suggests changes, or accepts it and initiates a review. Of course, 
>>> if this is incorrect, please let me know so I can do whatever next steps 
>>> there are :-)
>>> 
>>> Thanks again for all the contributions to this proposal, hope we see it get 
>>> approved soon!
>>> Riley
>>> 
 On Apr 4, 2016, at 11:58 AM, Riley Testut > wrote:
 
 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
  
 
 
 Planning on submitting the PR later tonight, so please let me know if you 
 have any last minute feedback!
 Riley
 
> On Mar 30, 2016, at 1:35 PM, Jonathan Hull  > wrote:
> 
> Probably ‘no' in this proposal to keep things simple.
> 
> Long term, I would like overriding of the factory init to be the 
> mechanism for a post-hoc extendable factory.  Disallowing it now probably 
> makes that easier in the future.
> 
> Thanks,
> Jon
> 
> 
>> On Mar 30, 2016, at 1:20 PM, Riley Testut > > wrote:
>> 
>> Another point to consider: should factory initializers be able to be 
>> overridden by subclasses? I vote no, just as you can't override 
>> convenience initializers.
>> 
>> On Mar 30, 2016, at 3:50 AM, Jonathan Hull > > wrote:
>> 
>>> 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 would be that people would be confused on when to 
>>> use ClassName() and when to use self.init().  Best to choose one and 
>>> stick with it.
>>> 
>>> Thanks,
>>> Jon
>>> 
 On Mar 30, 2016, at 3:36 AM, Riley Testut > wrote:
 
 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:
 
 public class ConcreteBase {
 
private 

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

[Goffredo Marocchi via swift-evolution]

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 “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 
> is impossible, and so I have to write NSTimer.new(…) :(
> 2. I wanted to add a custom initializer to a class inheriting from UIButton. 
> But I can’t, because the initializer for UIButton is `convenience init(type 
> buttonType: UIButtonType)` :(
> 
> A `factory init` allowing me to use both the initializer syntax and return an 
> object from some other initializer would solve both problems. The 
> "Initializing Storyboard-backed View Controller” use case is also compelling 
> to me.
> 
> +1.
> 
> — Radek
> 
>> On 09 Apr 2016, at 21:17, Riley Testut via swift-evolution 
>>  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
>> 
>> As far as I know, now we wait until a core team member reviews the PR, and 
>> either suggests changes, or accepts it and initiates a review. Of course, if 
>> this is incorrect, please let me know so I can do whatever next steps there 
>> are :-)
>> 
>> Thanks again for all the contributions to this proposal, hope we see it get 
>> approved soon!
>> Riley
>> 
>>> On Apr 4, 2016, at 11:58 AM, Riley Testut  wrote:
>>> 
>>> 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
>>> 
>>> Planning on submitting the PR later tonight, so please let me know if you 
>>> have any last minute feedback!
>>> Riley
>>> 
 On Mar 30, 2016, at 1:35 PM, Jonathan Hull  wrote:
 
 Probably ‘no' in this proposal to keep things simple.
 
 Long term, I would like overriding of the factory init to be the mechanism 
 for a post-hoc extendable factory.  Disallowing it now probably makes that 
 easier in the future.
 
 Thanks,
 Jon
 
 
> On Mar 30, 2016, at 1:20 PM, Riley Testut  wrote:
> 
> Another point to consider: should factory initializers be able to be 
> overridden by subclasses? I vote no, just as you can't override 
> convenience initializers.
> 
>> On Mar 30, 2016, at 3:50 AM, Jonathan Hull  wrote:
>> 
>> 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 would be that people would be confused on when to 
>> use ClassName() and when to use self.init().  Best to choose one and 
>> stick with it.
>> 
>> Thanks,
>> Jon
>> 
>>> On Mar 30, 2016, at 3:36 AM, Riley Testut  wrote:
>>> 
>>> 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:
>>> 
>>> public class ConcreteBase {
>>> 
>>> private init(type2: InformationToSwitchOn) {
>>> //Default implementation here
>>> }
>>> 
>>> public factory init (type: InformationToSwitchOn) {
>>> if … {
>>> return SpecialSubclass(type)  //Handle a 
>>> special case with a more efficient implementation
>>> }
>>> return ConcreteBase(type) //Handle the general case 
>>> with the main class
>>> }
>>> }
>>> 
>>> class SpecialSubclass : ConcreteBase {}
>>> 
 On Mar 30, 2016, at 3:30 AM, Jonathan Hull  wrote:
 
 Doh!  
 
 Sorry, typed that up in mail while working on something else at the 
 same time.  We shouldn’t allow an init with the same signature.  
 self.init() could be called with different parameters.  Trying to call 
 the factory method from the factory method should generate an error.
 
 We probably also want to disallow having an init with the same 
 signature in 

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

[Jonathan Hull via swift-evolution]

+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 
> 
> 
> As far as I know, now we wait until a core team member reviews the PR, and 
> either suggests changes, or accepts it and initiates a review. Of course, if 
> this is incorrect, please let me know so I can do whatever next steps there 
> are :-)
> 
> Thanks again for all the contributions to this proposal, hope we see it get 
> approved soon!
> Riley
> 
>> On Apr 4, 2016, at 11:58 AM, Riley Testut > > wrote:
>> 
>> 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
>>  
>> 
>> 
>> Planning on submitting the PR later tonight, so please let me know if you 
>> have any last minute feedback!
>> Riley
>> 
>>> On Mar 30, 2016, at 1:35 PM, Jonathan Hull >> > wrote:
>>> 
>>> Probably ‘no' in this proposal to keep things simple.
>>> 
>>> Long term, I would like overriding of the factory init to be the mechanism 
>>> for a post-hoc extendable factory.  Disallowing it now probably makes that 
>>> easier in the future.
>>> 
>>> Thanks,
>>> Jon
>>> 
>>> 
 On Mar 30, 2016, at 1:20 PM, Riley Testut > wrote:
 
 Another point to consider: should factory initializers be able to be 
 overridden by subclasses? I vote no, just as you can't override 
 convenience initializers.
 
 On Mar 30, 2016, at 3:50 AM, Jonathan Hull > wrote:
 
> 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 would be that people would be confused on when to use ClassName() 
> and when to use self.init().  Best to choose one and stick with it.
> 
> Thanks,
> Jon
> 
>> On Mar 30, 2016, at 3:36 AM, Riley Testut > > wrote:
>> 
>> 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:
>> 
>> public class ConcreteBase {
>> 
>>  private init(type2: InformationToSwitchOn) {
>>  //Default implementation here
>>  }
>> 
>>  public factory init (type: InformationToSwitchOn) {
>>  if … {
>>  return SpecialSubclass(type)  //Handle a special case 
>> with a more efficient implementation
>>  }
>>  return ConcreteBase(type) //Handle the general case with the 
>> main class
>>  }
>> }
>> 
>> class SpecialSubclass : ConcreteBase {}
>> 
>>> On Mar 30, 2016, at 3:30 AM, Jonathan Hull >> > wrote:
>>> 
>>> Doh!  
>>> 
>>> Sorry, typed that up in mail while working on something else at the 
>>> same time.  We shouldn’t allow an init with the same signature.  
>>> self.init() could be called with different parameters.  Trying to call 
>>> the factory method from the factory method should generate an error.
>>> 
>>> We probably also want to disallow having an init with the same 
>>> signature in subclasses as well (we could pass the same info with 
>>> different parameter names) as a subclass which doesn’t override it 
>>> would again be calling the factory method.  Ultimately, I would like to 
>>> see the ability to override the factory method with the behavior I 
>>> described earlier… but that is for a later proposal.
>>> 
>>> Basically we should be able to return anything which adheres to the 
>>> type, so we are free to use other initializers on the class/subclasses.
>>> 
>>> Thanks,
>>> Jon
>>> 
>>> 
 On Mar 30, 2016, at 3:10 AM, Riley Testut > wrote:
 
 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 

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

[Radosław Pietruszewski via swift-evolution]

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 is 
impossible, and so I have to write NSTimer.new(…) 

 :(
2. I wanted to add a custom initializer to a class inheriting from UIButton. 
But I can’t, because the initializer for UIButton is `convenience init(type 
buttonType: UIButtonType)` :(

A `factory init` allowing me to use both the initializer syntax and return an 
object from some other initializer would solve both problems. The "Initializing 
Storyboard-backed View Controller” use case is also compelling to me.

+1.

— Radek

> On 09 Apr 2016, at 21:17, Riley Testut via swift-evolution 
>  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 
> 
> 
> As far as I know, now we wait until a core team member reviews the PR, and 
> either suggests changes, or accepts it and initiates a review. Of course, if 
> this is incorrect, please let me know so I can do whatever next steps there 
> are :-)
> 
> Thanks again for all the contributions to this proposal, hope we see it get 
> approved soon!
> Riley
> 
>> On Apr 4, 2016, at 11:58 AM, Riley Testut > > wrote:
>> 
>> 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
>>  
>> 
>> 
>> Planning on submitting the PR later tonight, so please let me know if you 
>> have any last minute feedback!
>> Riley
>> 
>>> On Mar 30, 2016, at 1:35 PM, Jonathan Hull >> > wrote:
>>> 
>>> Probably ‘no' in this proposal to keep things simple.
>>> 
>>> Long term, I would like overriding of the factory init to be the mechanism 
>>> for a post-hoc extendable factory.  Disallowing it now probably makes that 
>>> easier in the future.
>>> 
>>> Thanks,
>>> Jon
>>> 
>>> 
 On Mar 30, 2016, at 1:20 PM, Riley Testut > wrote:
 
 Another point to consider: should factory initializers be able to be 
 overridden by subclasses? I vote no, just as you can't override 
 convenience initializers.
 
 On Mar 30, 2016, at 3:50 AM, Jonathan Hull > wrote:
 
> 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 would be that people would be confused on when to use ClassName() 
> and when to use self.init().  Best to choose one and stick with it.
> 
> Thanks,
> Jon
> 
>> On Mar 30, 2016, at 3:36 AM, Riley Testut > > wrote:
>> 
>> 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:
>> 
>> public class ConcreteBase {
>> 
>>  private init(type2: InformationToSwitchOn) {
>>  //Default implementation here
>>  }
>> 
>>  public factory init (type: InformationToSwitchOn) {
>>  if … {
>>  return SpecialSubclass(type)  //Handle a special case 
>> with a more efficient implementation
>>  }
>>  return ConcreteBase(type) //Handle the general case with the 
>> main class
>>  }
>> }
>> 
>> class SpecialSubclass : ConcreteBase {}
>> 
>>> On Mar 30, 2016, at 3:30 AM, Jonathan Hull >> > wrote:
>>> 
>>> Doh!  
>>> 
>>> Sorry, typed that up in mail while working on something else at the 
>>> same time.  We shouldn’t allow an init with the same signature.  
>>> self.init() could be called with different parameters.  Trying to call 
>>> the factory method from the factory method should generate an error.
>>> 
>>> We probably also want to disallow having an init with the 

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

[Riley Testut via swift-evolution]

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
 


Planning on submitting the PR later tonight, so please let me know if you have 
any last minute feedback!
Riley

> On Mar 30, 2016, at 1:35 PM, Jonathan Hull  wrote:
> 
> Probably ‘no' in this proposal to keep things simple.
> 
> Long term, I would like overriding of the factory init to be the mechanism 
> for a post-hoc extendable factory.  Disallowing it now probably makes that 
> easier in the future.
> 
> Thanks,
> Jon
> 
> 
>> On Mar 30, 2016, at 1:20 PM, Riley Testut > > wrote:
>> 
>> Another point to consider: should factory initializers be able to be 
>> overridden by subclasses? I vote no, just as you can't override convenience 
>> initializers.
>> 
>> On Mar 30, 2016, at 3:50 AM, Jonathan Hull > > wrote:
>> 
>>> 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 
>>> would be that people would be confused on when to use ClassName() and when 
>>> to use self.init().  Best to choose one and stick with it.
>>> 
>>> Thanks,
>>> Jon
>>> 
 On Mar 30, 2016, at 3:36 AM, Riley Testut > wrote:
 
 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:
 
 public class ConcreteBase {
 
private init(type2: InformationToSwitchOn) {
//Default implementation here
}
 
public factory init (type: InformationToSwitchOn) {
if … {
return SpecialSubclass(type)  //Handle a special case 
 with a more efficient implementation
}
return ConcreteBase(type) //Handle the general case with the 
 main class
}
 }
 
 class SpecialSubclass : ConcreteBase {}
 
> On Mar 30, 2016, at 3:30 AM, Jonathan Hull  > wrote:
> 
> Doh!  
> 
> Sorry, typed that up in mail while working on something else at the same 
> time.  We shouldn’t allow an init with the same signature.  self.init() 
> could be called with different parameters.  Trying to call the factory 
> method from the factory method should generate an error.
> 
> We probably also want to disallow having an init with the same signature 
> in subclasses as well (we could pass the same info with different 
> parameter names) as a subclass which doesn’t override it would again be 
> calling the factory method.  Ultimately, I would like to see the ability 
> to override the factory method with the behavior I described earlier… but 
> that is for a later proposal.
> 
> Basically we should be able to return anything which adheres to the type, 
> so we are free to use other initializers on the class/subclasses.
> 
> Thanks,
> Jon
> 
> 
>> On Mar 30, 2016, at 3:10 AM, Riley Testut > > wrote:
>> 
>> 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 >> > wrote:
>>> 
>>> 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 we should 
>>> also allow self.init() to be called from the factory init (similar to a 
>>> convenience init).  It could still be used with an AbstractBase as 
>>> shown in your example (especially when dealing with protocols), but it 
>>> shouldn’t force us to be abstract in the class case.
>>> 
>>> In other words, we should also be able to do the following:
>>> 
>>> public class ConcreteBase {
>>> 
>>> 

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

[Jonathan Hull via swift-evolution]

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 would be that 
people would be confused on when to use ClassName() and when to use 
self.init().  Best to choose one and stick with it.

Thanks,
Jon

> On Mar 30, 2016, at 3:36 AM, Riley Testut  wrote:
> 
> 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:
> 
> public class ConcreteBase {
> 
>   private init(type2: InformationToSwitchOn) {
>   //Default implementation here
>   }
> 
>   public factory init (type: InformationToSwitchOn) {
>   if … {
>   return SpecialSubclass(type)  //Handle a special case 
> with a more efficient implementation
>   }
>   return ConcreteBase(type) //Handle the general case with the 
> main class
>   }
> }
> 
> class SpecialSubclass : ConcreteBase {}
> 
>> On Mar 30, 2016, at 3:30 AM, Jonathan Hull > > wrote:
>> 
>> Doh!  
>> 
>> Sorry, typed that up in mail while working on something else at the same 
>> time.  We shouldn’t allow an init with the same signature.  self.init() 
>> could be called with different parameters.  Trying to call the factory 
>> method from the factory method should generate an error.
>> 
>> We probably also want to disallow having an init with the same signature in 
>> subclasses as well (we could pass the same info with different parameter 
>> names) as a subclass which doesn’t override it would again be calling the 
>> factory method.  Ultimately, I would like to see the ability to override the 
>> factory method with the behavior I described earlier… but that is for a 
>> later proposal.
>> 
>> Basically we should be able to return anything which adheres to the type, so 
>> we are free to use other initializers on the class/subclasses.
>> 
>> Thanks,
>> Jon
>> 
>> 
>>> On Mar 30, 2016, at 3:10 AM, Riley Testut >> > wrote:
>>> 
>>> 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 > wrote:
 
 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 we should also 
 allow self.init() to be called from the factory init (similar to a 
 convenience init).  It could still be used with an AbstractBase as shown 
 in your example (especially when dealing with protocols), but it shouldn’t 
 force us to be abstract in the class case.
 
 In other words, we should also be able to do the following:
 
 public class ConcreteBase {
 
private init(type: InformationToSwitchOn) {
//Default implementation here
}
 
public factory init (type: InformationToSwitchOn) {
if … {
return SpecialSubclass(type)  //Handle a special case 
 with a more efficient implementation
}
return self.init(type) //Handle the general case with the main 
 class
}
 }
 
 class SpecialSubclass : ConcreteBase {}
 
 
 
 The behavior should simply be that we can return any init’d object that 
 conforms to the given type.
 
 Thanks,
 Jon
 
 
> On Mar 30, 2016, at 2:20 AM, Riley Testut  > wrote:
> 
> 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 it.
> 
> That being said, I’ve written up essentially a final version of the 
> proposal, which you can find here: 
> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
>  
> 

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

[Riley Testut via swift-evolution]

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:

public class ConcreteBase {

private init(type2: InformationToSwitchOn) {
//Default implementation here
}

public factory init (type: InformationToSwitchOn) {
if … {
return SpecialSubclass(type)  //Handle a special case 
with a more efficient implementation
}
return ConcreteBase(type) //Handle the general case with the 
main class
}
}

class SpecialSubclass : ConcreteBase {}

> On Mar 30, 2016, at 3:30 AM, Jonathan Hull  wrote:
> 
> Doh!  
> 
> Sorry, typed that up in mail while working on something else at the same 
> time.  We shouldn’t allow an init with the same signature.  self.init() could 
> be called with different parameters.  Trying to call the factory method from 
> the factory method should generate an error.
> 
> We probably also want to disallow having an init with the same signature in 
> subclasses as well (we could pass the same info with different parameter 
> names) as a subclass which doesn’t override it would again be calling the 
> factory method.  Ultimately, I would like to see the ability to override the 
> factory method with the behavior I described earlier… but that is for a later 
> proposal.
> 
> Basically we should be able to return anything which adheres to the type, so 
> we are free to use other initializers on the class/subclasses.
> 
> Thanks,
> Jon
> 
> 
>> On Mar 30, 2016, at 3:10 AM, Riley Testut > > wrote:
>> 
>> 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 >> > wrote:
>>> 
>>> 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 we should also 
>>> allow self.init() to be called from the factory init (similar to a 
>>> convenience init).  It could still be used with an AbstractBase as shown in 
>>> your example (especially when dealing with protocols), but it shouldn’t 
>>> force us to be abstract in the class case.
>>> 
>>> In other words, we should also be able to do the following:
>>> 
>>> public class ConcreteBase {
>>> 
>>> private init(type: InformationToSwitchOn) {
>>> //Default implementation here
>>> }
>>> 
>>> public factory init (type: InformationToSwitchOn) {
>>> if … {
>>> return SpecialSubclass(type)  //Handle a special case 
>>> with a more efficient implementation
>>> }
>>> return self.init(type) //Handle the general case with the main 
>>> class
>>> }
>>> }
>>> 
>>> class SpecialSubclass : ConcreteBase {}
>>> 
>>> 
>>> 
>>> The behavior should simply be that we can return any init’d object that 
>>> conforms to the given type.
>>> 
>>> Thanks,
>>> Jon
>>> 
>>> 
 On Mar 30, 2016, at 2:20 AM, Riley Testut > wrote:
 
 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 it.
 
 That being said, I’ve written up essentially a final version of the 
 proposal, which you can find here: 
 https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
  
 .
  Assuming everyone is happy with it, I’ll send a pull request in the next 
 few days to the main-repo. But please, give any last minute feedback now!
 
> On Mar 24, 2016, at 5:12 PM, Jonathan Hull  > wrote:
> 
> 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, 

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

[Riley Testut via swift-evolution]

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  wrote:
> 
> 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 we should also 
> allow self.init() to be called from the factory init (similar to a 
> convenience init).  It could still be used with an AbstractBase as shown in 
> your example (especially when dealing with protocols), but it shouldn’t force 
> us to be abstract in the class case.
> 
> In other words, we should also be able to do the following:
> 
> public class ConcreteBase {
> 
>   private init(type: InformationToSwitchOn) {
>   //Default implementation here
>   }
> 
>   public factory init (type: InformationToSwitchOn) {
>   if … {
>   return SpecialSubclass(type)  //Handle a special case 
> with a more efficient implementation
>   }
>   return self.init(type) //Handle the general case with the main 
> class
>   }
> }
> 
> class SpecialSubclass : ConcreteBase {}
> 
> 
> 
> The behavior should simply be that we can return any init’d object that 
> conforms to the given type.
> 
> Thanks,
> Jon
> 
> 
>> On Mar 30, 2016, at 2:20 AM, Riley Testut > > wrote:
>> 
>> 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 it.
>> 
>> That being said, I’ve written up essentially a final version of the 
>> proposal, which you can find here: 
>> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
>>  
>> .
>>  Assuming everyone is happy with it, I’ll send a pull request in the next 
>> few days to the main-repo. But please, give any last minute feedback now!
>> 
>>> On Mar 24, 2016, at 5:12 PM, Jonathan Hull >> > wrote:
>>> 
>>> 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 as minimalistic as 
 possible, while still providing enough flexibility and use cases to 
 warrant it.
>>> 
>>> I can definitely see the argument that extensibility is out of scope for 
>>> Swift 3, but I do want to make sure that it is possible for us to have 
>>> extensibility in the future (that we don’t block ourselves from doing it).
>>> 
>>> I strongly disagree that the gain is small.  One of the core benefits of 
>>> both Swift/ObjC (and now POP) is the ability to extend things post-hoc, 
>>> without access to the original code.
>>> 
>>> I often write libraries & SDKs, so the users of my code don't have access 
>>> to the original code.  I guess extensibility is less necessary when you 
>>> control the entire codebase, but you still have to refactor your factory 
>>> whenever you subclass (or adhere to a protocol), which I find problematic.
>>> 
>>> This is something I run into a lot while writing actual code, so it isn’t 
>>> just a theoretical concern.
>>> 
>>> 
>>> 
 Interesting you bring up the registering of subclasses, as that is similar 
 to the very original proposal, and actually similar to what I'm doing in 
 my own app. Effectively, I have an Objective-C base class, and in +load it 
 dynamically finds all subclasses using the Objective-C runtime, and stores 
 a reference to them. Then in the initializer, it returns the appropriate 
 subclass based on the initialization parameters. This was my solution to 
 the superclass not having to explicitly know each individual subclass.
 
 Using factory initializers, however, this pattern could be used in pure 
 Swift, albeit with some minor modifications. At program start, the program 
 could register subclasses with the superclass, and then in the initializer 
 would simply return the appropriate subclass (similar to NSURLProtocol, I 
 believe).
>>> 
>>> Yes, I have also used load in this way in ObjC.  In Swift, I think the 
>>> compiler could 

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

[Jonathan Hull via swift-evolution]

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 we should also allow 
self.init() to be called from the factory init (similar to a convenience init). 
 It could still be used with an AbstractBase as shown in your example 
(especially when dealing with protocols), but it shouldn’t force us to be 
abstract in the class case.

In other words, we should also be able to do the following:

public class ConcreteBase {

private init(type: InformationToSwitchOn) {
//Default implementation here
}

public factory init (type: InformationToSwitchOn) {
if … {
return SpecialSubclass(type)  //Handle a special case 
with a more efficient implementation
}
return self.init(type) //Handle the general case with the main 
class
}
}

class SpecialSubclass : ConcreteBase {}



The behavior should simply be that we can return any init’d object that 
conforms to the given type.

Thanks,
Jon


> On Mar 30, 2016, at 2:20 AM, Riley Testut  wrote:
> 
> 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 it.
> 
> That being said, I’ve written up essentially a final version of the proposal, 
> which you can find here: 
> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
>  
> .
>  Assuming everyone is happy with it, I’ll send a pull request in the next few 
> days to the main-repo. But please, give any last minute feedback now!
> 
>> On Mar 24, 2016, at 5:12 PM, Jonathan Hull > > wrote:
>> 
>> 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 as minimalistic as 
>>> possible, while still providing enough flexibility and use cases to warrant 
>>> it.
>> 
>> I can definitely see the argument that extensibility is out of scope for 
>> Swift 3, but I do want to make sure that it is possible for us to have 
>> extensibility in the future (that we don’t block ourselves from doing it).
>> 
>> I strongly disagree that the gain is small.  One of the core benefits of 
>> both Swift/ObjC (and now POP) is the ability to extend things post-hoc, 
>> without access to the original code.
>> 
>> I often write libraries & SDKs, so the users of my code don't have access to 
>> the original code.  I guess extensibility is less necessary when you control 
>> the entire codebase, but you still have to refactor your factory whenever 
>> you subclass (or adhere to a protocol), which I find problematic.
>> 
>> This is something I run into a lot while writing actual code, so it isn’t 
>> just a theoretical concern.
>> 
>> 
>> 
>>> Interesting you bring up the registering of subclasses, as that is similar 
>>> to the very original proposal, and actually similar to what I'm doing in my 
>>> own app. Effectively, I have an Objective-C base class, and in +load it 
>>> dynamically finds all subclasses using the Objective-C runtime, and stores 
>>> a reference to them. Then in the initializer, it returns the appropriate 
>>> subclass based on the initialization parameters. This was my solution to 
>>> the superclass not having to explicitly know each individual subclass.
>>> 
>>> Using factory initializers, however, this pattern could be used in pure 
>>> Swift, albeit with some minor modifications. At program start, the program 
>>> could register subclasses with the superclass, and then in the initializer 
>>> would simply return the appropriate subclass (similar to NSURLProtocol, I 
>>> believe).
>> 
>> Yes, I have also used load in this way in ObjC.  In Swift, I think the 
>> compiler could easily build an array/table of the overloads of factory 
>> inits.  This avoids having to register explicitly (the declaration itself 
>> implies intent to register), and doesn’t take up any cycles during execution.
>> 
>> I ran into the problem of when to register the other day in a current 
>> project, as Swift doesn’t have an equivalent to +load that I am aware of.  I 
>> had to settle for something of a hack which gets called on first use… but it 
>> was only a 

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

[Riley Testut via swift-evolution]

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 it.

That being said, I’ve written up essentially a final version of the proposal, 
which you can find here: 
https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md.
 Assuming everyone is happy with it, I’ll send a pull request in the next few 
days to the main-repo. But please, give any last minute feedback now!

> On Mar 24, 2016, at 5:12 PM, Jonathan Hull  wrote:
> 
> 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 as minimalistic as possible, while 
>> still providing enough flexibility and use cases to warrant it.
> 
> I can definitely see the argument that extensibility is out of scope for 
> Swift 3, but I do want to make sure that it is possible for us to have 
> extensibility in the future (that we don’t block ourselves from doing it).
> 
> I strongly disagree that the gain is small.  One of the core benefits of both 
> Swift/ObjC (and now POP) is the ability to extend things post-hoc, without 
> access to the original code.
> 
> I often write libraries & SDKs, so the users of my code don't have access to 
> the original code.  I guess extensibility is less necessary when you control 
> the entire codebase, but you still have to refactor your factory whenever you 
> subclass (or adhere to a protocol), which I find problematic.
> 
> This is something I run into a lot while writing actual code, so it isn’t 
> just a theoretical concern.
> 
> 
> 
>> Interesting you bring up the registering of subclasses, as that is similar 
>> to the very original proposal, and actually similar to what I'm doing in my 
>> own app. Effectively, I have an Objective-C base class, and in +load it 
>> dynamically finds all subclasses using the Objective-C runtime, and stores a 
>> reference to them. Then in the initializer, it returns the appropriate 
>> subclass based on the initialization parameters. This was my solution to the 
>> superclass not having to explicitly know each individual subclass.
>> 
>> Using factory initializers, however, this pattern could be used in pure 
>> Swift, albeit with some minor modifications. At program start, the program 
>> could register subclasses with the superclass, and then in the initializer 
>> would simply return the appropriate subclass (similar to NSURLProtocol, I 
>> believe).
> 
> Yes, I have also used load in this way in ObjC.  In Swift, I think the 
> compiler could easily build an array/table of the overloads of factory inits. 
>  This avoids having to register explicitly (the declaration itself implies 
> intent to register), and doesn’t take up any cycles during execution.
> 
> I ran into the problem of when to register the other day in a current 
> project, as Swift doesn’t have an equivalent to +load that I am aware of.  I 
> had to settle for something of a hack which gets called on first use… but it 
> was only a partial solution which worked in that particular case.  How do the 
> swift classes/enums/structs get called to register themselves?
> 
> We may want to propose adding a +load equivalent for Swift types, since it 
> does come up occasionally. It is one of those things which you don’t need 
> often, but when you do, you really need it.  Ironically, this was one of the 
> uses of the original feature I talked about earlier (we used it to provide 
> the equivalent of +load, awakeFromNib, etc… in the language). 
> 
> 
> 
>> As for rationale for protocol (factory) initializers, a common pattern I've 
>> come across when developing my internal frameworks is to design a protocol, 
>> and then to provide a default implementation of the protocol with a type 
>> (typically a struct). I feel this relationship could be bridged easier by 
>> simply returning this type from a protocol initializer, which could even 
>> potentially allow me to declare the actual type as private, so for all 
>> intents and purposes the client does simply get an initialized protocol 
>> object (similar in part to creating an anonymous class conforming to a 
>> protocol in Java).
> 
> I strongly agree that we should have factory initializers for protocols for 
> the reasons you state here, plus many others.  It just seems like a natural 
> fit.
> 
> 
> I would like to see a 3 stage approach:
> 
> Stage 1:  Declaring an init as “factory” allows you to return any fully 
> inited object which fits the type (including calling self.init like a 
> convenience 

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

[Jonathan Hull via swift-evolution]

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 as minimalistic as possible, while 
> still providing enough flexibility and use cases to warrant it.

I can definitely see the argument that extensibility is out of scope for Swift 
3, but I do want to make sure that it is possible for us to have extensibility 
in the future (that we don’t block ourselves from doing it).

I strongly disagree that the gain is small.  One of the core benefits of both 
Swift/ObjC (and now POP) is the ability to extend things post-hoc, without 
access to the original code.

I often write libraries & SDKs, so the users of my code don't have access to 
the original code.  I guess extensibility is less necessary when you control 
the entire codebase, but you still have to refactor your factory whenever you 
subclass (or adhere to a protocol), which I find problematic.

This is something I run into a lot while writing actual code, so it isn’t just 
a theoretical concern.



> Interesting you bring up the registering of subclasses, as that is similar to 
> the very original proposal, and actually similar to what I'm doing in my own 
> app. Effectively, I have an Objective-C base class, and in +load it 
> dynamically finds all subclasses using the Objective-C runtime, and stores a 
> reference to them. Then in the initializer, it returns the appropriate 
> subclass based on the initialization parameters. This was my solution to the 
> superclass not having to explicitly know each individual subclass.
> 
> Using factory initializers, however, this pattern could be used in pure 
> Swift, albeit with some minor modifications. At program start, the program 
> could register subclasses with the superclass, and then in the initializer 
> would simply return the appropriate subclass (similar to NSURLProtocol, I 
> believe).

Yes, I have also used load in this way in ObjC.  In Swift, I think the compiler 
could easily build an array/table of the overloads of factory inits.  This 
avoids having to register explicitly (the declaration itself implies intent to 
register), and doesn’t take up any cycles during execution.

I ran into the problem of when to register the other day in a current project, 
as Swift doesn’t have an equivalent to +load that I am aware of.  I had to 
settle for something of a hack which gets called on first use… but it was only 
a partial solution which worked in that particular case.  How do the swift 
classes/enums/structs get called to register themselves?

We may want to propose adding a +load equivalent for Swift types, since it does 
come up occasionally. It is one of those things which you don’t need often, but 
when you do, you really need it.  Ironically, this was one of the uses of the 
original feature I talked about earlier (we used it to provide the equivalent 
of +load, awakeFromNib, etc… in the language). 



> As for rationale for protocol (factory) initializers, a common pattern I've 
> come across when developing my internal frameworks is to design a protocol, 
> and then to provide a default implementation of the protocol with a type 
> (typically a struct). I feel this relationship could be bridged easier by 
> simply returning this type from a protocol initializer, which could even 
> potentially allow me to declare the actual type as private, so for all 
> intents and purposes the client does simply get an initialized protocol 
> object (similar in part to creating an anonymous class conforming to a 
> protocol in Java).

I strongly agree that we should have factory initializers for protocols for the 
reasons you state here, plus many others.  It just seems like a natural fit.


I would like to see a 3 stage approach:

Stage 1:  Declaring an init as “factory” allows you to return any fully inited 
object which fits the type (including calling self.init like a convenience init 
would and then returning it). If the init is failable, you can also return nil. 
 This works both on classes and protocols.

Stage 2:  The compiler builds a table of the overrides of a given factory init, 
and there is some syntax to call them (e.g. “let sub = subclasses.init(value)”) 
such that the first one to return non-nil is the return value to that call.  
Thorsten’s depth first + alphabetical ordering would be adequate to make the 
behavior predictable.  Again, this should work for both classes and protocols. 
(I am open to better ideas for syntax/naming)

Stage 3: We allow greater control over the ordering in the table. This still 
needs thought both on syntax and method.  Something similar to operator 
precedence (or autolayout priority) would work in a pinch, but isn’t super 
elegant. In practice, it might be enough just to be able to declare that 
something needs to be 

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

[rintaro ishizaki via swift-evolution]

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 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 there still an interest in the proposal? If so, I'll write up a new
> proposal with everyone's feedback, and then post it here for more
> discussion. I think this would very valuable (and would certainly help a
> bunch in my current app), but want to see where everyone stands!
>
> Riley Testut
>
> On Feb 8, 2016, at 11:26 AM, Charles Srstka 
> wrote:
>
> >> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> 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:
> >>
> >> # Factory Initializers
> >>
> >> 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.
> >>
> >> 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:
> >>
> >> class AbstractBase {
> >>   public factory init(type: InformationToSwitchOn) {
> >>   return ConcreteImplementation(type)
> >>   }
> >> }
> >>
> >> class ConcreteImplementation : AbstractBase {
> >>
> >> }
> >>
> >> 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:
> >>
> >> ## Class Cluster/Abstract Classes
> >> 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.
> >>
> >> ## Protocol Initializers
> >> 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.
> >>
> >> ## Initializing Storyboard-backed View Controller
> >> 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.
> >>
> >> Here are some comments from the previous thread that I believe are
> still relevant:
> >>
> >>
> >>> On Dec 9, 2015, at 1:06 PM, Philippe Hausler 
> wrote:
> >>>
> >>> I can definitely attest that in implementing Foundation we could have
> much more idiomatic swift and much more similar behavior to the way
> 

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

[Riley Testut via swift-evolution]

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.

Interesting you bring up the registering of subclasses, as that is similar to 
the very original proposal, and actually similar to what I'm doing in my own 
app. Effectively, I have an Objective-C base class, and in +load it dynamically 
finds all subclasses using the Objective-C runtime, and stores a reference to 
them. Then in the initializer, it returns the appropriate subclass based on the 
initialization parameters. This was my solution to the superclass not having to 
explicitly know each individual subclass.

Using factory initializers, however, this pattern could be used in pure Swift, 
albeit with some minor modifications. At program start, the program could 
register subclasses with the superclass, and then in the initializer would 
simply return the appropriate subclass (similar to NSURLProtocol, I believe).

As for rationale for protocol (factory) initializers, a common pattern I've 
come across when developing my internal frameworks is to design a protocol, and 
then to provide a default implementation of the protocol with a type (typically 
a struct). I feel this relationship could be bridged easier by simply returning 
this type from a protocol initializer, which could even potentially allow me to 
declare the actual type as private, so for all intents and purposes the client 
does simply get an initialized protocol object (similar in part to creating an 
anonymous class conforming to a protocol in Java).

> On Mar 22, 2016, at 5:21 PM, Jonathan Hull  wrote:
> 
> 
> 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 come up with something which 
> completely solves it… and I think factories get us only part way there. Let’s 
> take a moment and see if we can create something uniquely swift before we 
> copy/paste existing solutions.
> Think about Cocoa’s class clusters for a moment. I love them, but they are a 
> pain to subclass. To the level where any beginning Cocoa instruction tells 
> you explicitly not to subclass them. Similarly, even in my own factories, 
> they are always a pain to extend.
> I want our factory inits to be extensible by default.
> 
> By extensible, I mean that I want to be able to add a new subclass (or a new 
> entity satisfying a protocol), and have it come out of the factory when 
> appropriate without editing the base class! Madness, I know, but:
> 1) I may not have access to the source of the base class (e.g. Cocoa 
> Collections)
> 2) I always feel a bit dirty giving the base class knowledge of it’s 
> subclasses
> 3) It is a royal pain, and a potential source of errors as things get 
> refactored when adding new subclasses
> 
> I think I have at least the seed of an idea of how to solve this, and I am 
> hoping that one of you (who are all much smarter than I) might have the key 
> to getting it the rest of the way.
> I ran into this problem again last week, and it made me think of an old 
> language I used to use...
> There was a small programming language I used to use in the 90’s which had an 
> interesting core language feature we called “handlers”. These were a lot like 
> registering for notifications, except that writing a function (with a special 
> “Handler” attribute: “Handler func myFuncName()") was all you needed to do to 
> register. Writing “Handle myFuncName()” would then systematically call every 
> function with that name and the Handler attribute.
> That is, instead of calling a single function, it would systematically call a 
> series of functions (all with the same name).
> There was one other thing that made these handlers special. Each one had the 
> option, when it was called, to reply that it was the one true handler, and 
> the others didn’t need to be called. Basically, it said “I've got this!”. 
> This even allowed it to return a result to the caller.
> The original intent of this feature (and why it was a core language feature) 
> was to handle events. It would handle things like hit testing and key events 
> fairly elegantly. It was a powerful feature, so it was quickly used for other 
> things. It made things like plug-ins ridiculously simple. We even used it for 
> a form of error handling.
> I remember helping to write a page layout program in it, and we used handlers 
> not just for the hit testing, but for the tool palette as well. The end 
> result was that you were able to add new shapes and new tools without 
> modifying existing code at all. It is a feature I miss 

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

[Jonathan Hull via swift-evolution]

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 come up with something which 
completely solves it… and I think factories get us only part way there. Let’s 
take a moment and see if we can create something uniquely swift before we 
copy/paste existing solutions.
Think about Cocoa’s class clusters for a moment. I love them, but they are a 
pain to subclass. To the level where any beginning Cocoa instruction tells you 
explicitly not to subclass them. Similarly, even in my own factories, they are 
always a pain to extend.
I want our factory inits to be extensible by default.

By extensible, I mean that I want to be able to add a new subclass (or a new 
entity satisfying a protocol), and have it come out of the factory when 
appropriate without editing the base class! Madness, I know, but:
1) I may not have access to the source of the base class (e.g. Cocoa 
Collections)
2) I always feel a bit dirty giving the base class knowledge of it’s subclasses
3) It is a royal pain, and a potential source of errors as things get 
refactored when adding new subclasses

I think I have at least the seed of an idea of how to solve this, and I am 
hoping that one of you (who are all much smarter than I) might have the key to 
getting it the rest of the way.
I ran into this problem again last week, and it made me think of an old 
language I used to use...
There was a small programming language I used to use in the 90’s which had an 
interesting core language feature we called “handlers”. These were a lot like 
registering for notifications, except that writing a function (with a special 
“Handler” attribute: “Handler func myFuncName()") was all you needed to do to 
register. Writing “Handle myFuncName()” would then systematically call every 
function with that name and the Handler attribute.
That is, instead of calling a single function, it would systematically call a 
series of functions (all with the same name).
There was one other thing that made these handlers special. Each one had the 
option, when it was called, to reply that it was the one true handler, and the 
others didn’t need to be called. Basically, it said “I've got this!”. This even 
allowed it to return a result to the caller.
The original intent of this feature (and why it was a core language feature) 
was to handle events. It would handle things like hit testing and key events 
fairly elegantly. It was a powerful feature, so it was quickly used for other 
things. It made things like plug-ins ridiculously simple. We even used it for a 
form of error handling.
I remember helping to write a page layout program in it, and we used handlers 
not just for the hit testing, but for the tool palette as well. The end result 
was that you were able to add new shapes and new tools without modifying 
existing code at all. It is a feature I miss all the time...

That is more power than we need here, but it provided me the inspiration for a 
potential solution to the factory problem. Back to swift…

The idea here is to give each interested subclass a chance to say “I've got 
this!”. The factory init runs through each of the subclasses’ overrides until 
it finds one that doesn’t return nil. New subclasses can be added and they will 
be given a chance as well (without modifying the base class). The first 
subclass to successfully init wins. (only subclasses which override the factory 
init would be considered)

class AbstractBase {
public factory init?(type: InformationToSwitchOn){
//I like having an explicit call, so that the traditional 
(non-distributed) factory is possible as well
return factory.init(type) //We could also call this 
“subclass.init(type)” to mirror super
}
}
class ConcreteImplementation : AbstractBase {
public factory override init?(type: InformationToSwitchOn){
guard type == compatibleWithThisType else {return nil} //If info 
doesn’t work for us, we return nil, and the next class gets a shot
//Init concrete type here
}
}

The main issue which still needs to be solved is that the order they get called 
sometimes really matters (this was solved by a well defined ordering + IDE 
features in the language mentioned above). For the most part, as long as 
subclasses are called before their superclasses (or there is a some method for 
cascading), it works. There are still times where you want to define a specific 
ordering though (e.g. a new subclass wants to get called before an existing 
subclasses to override some of it’s use cases).
I see a few options (and I would love to hear more):
- subclasses define a numeric precedence (similar to operators now). This is 
probably the most effective stop-gap solution, but is not elegant.
- subclasses do whatever we change 

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

[David Waite via swift-evolution]

+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 injection (that your 
implementation should be given the instances of the abstraction you need rather 
than creating concrete classes on its own)

By having your code depend on a factory initializer at runtime to get its 
abstractions, you are limited in your ability to adapt the code to other 
scenarios such as testing. You may for instance need to put your factory 
initializer on your protocol into a ‘testing mode’ in order to perform unit 
testing on your code.

Or in other words, while its already possible to have factory methods and 
factory functions, I worry that factory initializers will result in APIs being 
unknowingly designed toward a higher degree of coupling in their code. Having 
factory initializers provides a greater degree of “blessing” in API design to 
(what I at least consider to be) an anti-pattern.

-DW

> On Mar 22, 2016, at 4:42 AM, Patrick Pijnappel via swift-evolution 
>  wrote:
> 
> 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 
> > wrote:
> 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 there still an interest in the proposal? If so, I'll write up a new 
> proposal with everyone's feedback, and then post it here for more discussion. 
> I think this would very valuable (and would certainly help a bunch in my 
> current app), but want to see where everyone stands!
> 
> Riley Testut
> 
> On Feb 8, 2016, at 11:26 AM, Charles Srstka  > wrote:
> 
> >> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
> >> > wrote:
> >>
> >> 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:
> >>
> >> # Factory Initializers
> >>
> >> 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.
> >>
> >> 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:
> >>
> >> class AbstractBase {
> >>   public factory init(type: InformationToSwitchOn) {
> >>   return ConcreteImplementation(type)
> >>   }
> >> }
> >>
> >> class ConcreteImplementation : AbstractBase {
> >>
> >> }
> >>
> >> 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:
> >>
> >> ## Class Cluster/Abstract Classes
> >> 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.
> >>
> >> ## Protocol Initializers
> >> 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 
> 

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

[Patrick Pijnappel via swift-evolution]

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-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 there still an interest in the proposal? If so, I'll write up a new
> proposal with everyone's feedback, and then post it here for more
> discussion. I think this would very valuable (and would certainly help a
> bunch in my current app), but want to see where everyone stands!
>
> Riley Testut
>
> On Feb 8, 2016, at 11:26 AM, Charles Srstka 
> wrote:
>
> >> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> 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:
> >>
> >> # Factory Initializers
> >>
> >> 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.
> >>
> >> 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:
> >>
> >> class AbstractBase {
> >>   public factory init(type: InformationToSwitchOn) {
> >>   return ConcreteImplementation(type)
> >>   }
> >> }
> >>
> >> class ConcreteImplementation : AbstractBase {
> >>
> >> }
> >>
> >> 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:
> >>
> >> ## Class Cluster/Abstract Classes
> >> 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.
> >>
> >> ## Protocol Initializers
> >> 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.
> >>
> >> ## Initializing Storyboard-backed View Controller
> >> 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.
> >>
> >> Here are some comments from the previous thread that I believe are
> still relevant:
> >>
> >>
> >>> On Dec 9, 2015, at 1:06 PM, Philippe Hausler 
> wrote:
> >>>
> >>> 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.
> 

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

[Riley Testut via swift-evolution]

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 there still an interest in the proposal? If so, I'll write up a new 
proposal with everyone's feedback, and then post it here for more discussion. I 
think this would very valuable (and would certainly help a bunch in my current 
app), but want to see where everyone stands!

Riley Testut

On Feb 8, 2016, at 11:26 AM, Charles Srstka  wrote:

>> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
>>  wrote:
>> 
>> 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:
>> 
>> # Factory Initializers
>> 
>> 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.
>> 
>> 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:
>> 
>> class AbstractBase {
>>   public factory init(type: InformationToSwitchOn) {
>>   return ConcreteImplementation(type)
>>   }
>> }
>> 
>> class ConcreteImplementation : AbstractBase {
>> 
>> }
>> 
>> 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:
>> 
>> ## Class Cluster/Abstract Classes
>> 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.
>> 
>> ## Protocol Initializers
>> 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.
>> 
>> ## Initializing Storyboard-backed View Controller
>> 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.
>> 
>> Here are some comments from the previous thread that I believe are still 
>> relevant:
>> 
>> 
>>> On Dec 9, 2015, at 1:06 PM, Philippe Hausler  wrote:
>>> 
>>> 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.
>> 
>> 
>>> On Dec 7, 2015, at 5:24 PM, Brent Royal-Gordon  
>>> wrote:
>>> 
>>> A `protocol init` in a protocol extension creates an initializer which is 
>>> *not* 

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

[Riley Testut via swift-evolution]

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 returning instances 
from convenience initializers, or should we simply assign to self? 

Personally, I think returning from the initializer makes the most sense, 
especially because "self" in a protocol extension seems ambiguous. However, I'm 
not that much in favor that I couldn't be convinced to simply assign to self, 
because that already has some low level support in the language. Anyone have 
strong thoughts one way or another?

> On Dec 22, 2015, at 1:00 PM, Charles Srstka  wrote:
> 
> Strong +1 on this, particularly on the part about protocol initializers. This 
> would bring together some of the best aspects of both Objective-C class 
> clusters and Swift protocol-oriented programming and would be a huge benefit 
> to application developers.
> 
> Charles
> 
>> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
>>  wrote:
>> 
>> 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:
>> 
>> # Factory Initializers
>> 
>> 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.
>> 
>> 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:
>> 
>> class AbstractBase {
>>   public factory init(type: InformationToSwitchOn) {
>>   return ConcreteImplementation(type)
>>   }
>> }
>> 
>> class ConcreteImplementation : AbstractBase {
>> 
>> }
>> 
>> 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:
>> 
>> ## Class Cluster/Abstract Classes
>> 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.
>> 
>> ## Protocol Initializers
>> 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.
>> 
>> ## Initializing Storyboard-backed View Controller
>> 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.
>> 
>> Here are some comments from the previous thread that I believe are still 
>> relevant:
>> 
>> 
>>> On Dec 9, 2015, at 1:06 PM, Philippe Hausler 

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

[Chris Lattner via swift-evolution]

> 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 AbstractBaseClass.
> Otherwise I would just call ConcreteImplementation(42) if I wanted something 
> of that static type.

Got it.  If that is the case, then yes, something like a “factory init” makes 
sense to me.  It is unfortunate that such a thing would make the swift 
initializer model even MORE complex :-) but it is probably still the right way 
to go.

-Chris

> 
> -Thorsten 
> 
>> Am 18.12.2015 um 01:25 schrieb Chris Lattner via swift-evolution 
>> :
>> 
>> 
>>> On Dec 17, 2015, at 1:41 PM, Riley Testut via swift-evolution 
>>>  wrote:
>>> 
>>> 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:
>>> 
>>> # Factory Initializers
>>> 
>>> 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.
>>> 
>>> 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:
>>> 
>>> class AbstractBase {
>>>  public factory init(type: InformationToSwitchOn) {
>>>  return ConcreteImplementation(type)
>>>  }
>>> }
>>> 
>>> class ConcreteImplementation : AbstractBase {
>>> 
>>> }
>> 
>> I’m confused, isn’t this already handled by “convenience” initializers?  
>> 
>> What we lack now is the ability to use the AbstractBase(42) syntax the 
>> produce something with a static type of ConcreteImplementation.  This is 
>> something expressible in Objective-C, and something that Swift can currently 
>> import into Objective-C, but that you can’t write directly in Swift code 
>> right now.
>> 
>> The approach that I would suggest is a simple extension of the grammar, to 
>> allow "-> T” on a convenience initializer.  In this case, you could write:
>> 
>> 
>> class AbstractBase {
>>  convenience init(type: InformationToSwitchOn) -> ConcreteImplementation {
>>  return ConcreteImplementation(type)
>>  }
>> 
>> and then "AbstractBase(stuff)” would produce a value with the static type of 
>> ConcreteImplementation.  This syntax is already produced by the AST printer 
>> for imported ObjC stuff, so we have much of the mechanics for this already 
>> in the compiler.  It would be great to see someone push this forward!
>> 
>> -Chris
>> 
>> 
>> 
>> 
>>> 
>>> 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:
>>> 
>>> ## Class Cluster/Abstract Classes
>>> 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.
>>> 
>>> ## Protocol Initializers
>>> 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.
>>> 
>>> ## Initializing Storyboard-backed View Controller
>>> 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