> On Mar 17, 2017, at 9:26 AM, Riley Testut via swift-evolution 
> <[email protected]> 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/NNNN-factory-initializers.md
>  
> <https://github.com/rileytestut/swift-evolution/blob/master/proposals/NNNN-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     [email protected]     Runtime Wrangler


_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to