[swift-evolution] [Pitch] Setup Block

[Andrew Arnopoulos]

I agree that this discussion would probably be benefit from being included in the "Add code to super methods” discussion. The one thing that worries me about the pitch is that it might muck up calling semantics. For example:

class Person {
    let firstName: String
    let lastName: String
    init(firstName: String, lastName: String) {
        self.firstName = firstName
        self.lastName = lastName
    }
    
    func printInformation() {
        print("\(firstName) \(lastName)")
    }
}

class Employee: Person {
    let id: String
    init(firstName: String, lastName: String, id: String) {
        self.id = id
        super.init(firstName: firstName, lastName: lastName)
    }
    
    override(before) func printInformation() {
        print("Employee \(id)")
    }
}

class PartTimeEmployee: Employee {
    let workdays: [Day]
    init(firstName: String, lastName: String, id: String, workdays: Day) {
        self.workdays = workdays
        super.init(firstName: firstName, lastName: lastName, id: id)
    }
    
    override(before) func printInformation() {
        print("Workdays: \(workdays)")
    }
}

If someone instantiates a PartTimeEmployee and calls printInformation how do the calling semantics work? Is PartTimeEmployee called before Employee or is it the other way around? Also, what happens when after or before isn’t used in a superclass that is a subclass of something else? When is before or after called in that situation?

Otherwise, I think the proposals are very similar and would benefit from being together both from a proposal and implementation stand point.

-Andrew

> On Nov 20, 2016, at 10:01 AM, Jay Abbott via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi Andrew,
> 
> There is a similar discussion (in that it solves some aspects of the same problem) going on at the moment with the subject "Add code to super methods" - check it out. The parts of this problem it doesn't address is that you would still have to override multiple init methods to ensure your common setup was called regardless of which initialiser is used. However, your idea of a post-init call might solve some of of the other issues being discussed there and affect that discussion quite a bit. In other words, I think these two ideas might benefit from being considered together rather than as separate issues.
> 
> On Sun, 20 Nov 2016 at 09:58 Tino Heth via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> Initialization is already quite complex in Swift, so I'm very wary of adding new features and prefer Derricks idea over a new language feature.
> I hope Swift is still flexible enough for deep changes in this area — I guess enforcing that there is always a single designated initializer would not only improve on you usecase.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161121/db92f490/attachment.html>