Sent from my iPhone > On 1 Apr 2017, at 00:35, Riley Testut via swift-evolution > <[email protected]> wrote: > > >> On Mar 20, 2017, at 8:07 PM, Greg Parker <[email protected]> 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 <[email protected]> >> 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 mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
