> On Dec 30, 2015, at 5:47 AM, Tino Heth <[email protected]> wrote: > > Have you looked at how this is handled in Kotlin?
I hadn’t, but I did look at a paper on a forwarding preprocessor for Java that was called Jaime. The way forwarding is declared is very similar to Kotlin so it may have been a predecessor: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.39.3374&rep=rep1&type=pdf <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.39.3374&rep=rep1&type=pdf> The initial approach I considered was similar. I show an example following your Kotlin example down below. > Imho Jetbrains solution is quite elegant — especially as it also has a > natural answer to another problem ("flexible memberwise initialization"; the > whole init process is only a short chapter in the docs). I don’t want this thread to get distracted with memberwise initialization so please move back to the appropriate thread if you want to discuss further. However, I will briefly respond here. Here is Kotlin: class Person constructor(firstName: String, lastName: String) { } Here is Swift under my proposal: class Person { var firstName: String var lastName: String // compiler synthesizes memberwise init } However, my proposal gives you a lot of additional flexibility: 1. It interacts well with access control 2. Partial memberwise initialization is possible 3. It allows memberwise initializers to accept non-memberwise parameters to initialize private state 4. More than one memberwise initializer is possible 5. Memberwise initialization of properties with declaration modifiers, behaviors / delegates is possible And probably more. My approach was to design a solution that fits into the current Swift language and is orthogonal to other language features as much as possible. If you feel Kotlin’s approach is better please respond to the memberwise initialization thread with some examples written in both Kotlin and in Swift using the memberwise initialization feature I am proposing to demonstrate how and why you think it is better. > Of course, their approach is different, but I'd rather copy from the best > than accept mediocrity because of the not invented here syndrome. Best is a judgement that depends on the criteria you are using to perform the evaluation. If it really is better using criteria appropriate for evaluating new features for Swift then of course that would be the way to go. I would never advocate different for the sake of different or NIH. > > [short explanation: In Kotlin, we would have > class Forwarder(forwardee: Forwardee): P by forwardee { > … > } > forwardee would be available as a member, and because it is introduced before > the protocol conformance, it can be used there without irritation. > Bonus: The designated initializer is defined at the same time. > ] One approach I considered would look like this: class Forwarder: P { // I didn’t like `implements` but didn’t have a better idea before I abandoned this approach var forwardee: Forwardee implements P } With the memberwise initialization proposal you also have the initializer synthesized automatically. The only thing it doesn’t do that your Kotlin example does is automatically declare conformance. This was an intentional design decision because it allows for additional expressivity. This is addressed in the alternatives considered section of the proposal. Another difference that is maybe subtle but I think important is that with the approach I considered forwarding is declared in the body of a type or extension which emphasizes the fact that forwarding is an implementation detail, not something users of the type should be concerned with. This approach was abandoned as it leads to problems in expressivity and clarity. Please see alternatives considered for an elaboration of that. This is especially true with the new approach to handling Self values that Brent suggested. That approach requires additional syntax around the forwarding declaration, but adds both clarity and expressiveness. It appears to me that you value conciseness very highly. I do value conciseness but I also value safety, clarity, and expressiveness. > > As for the implementation: > Why not simply make this feature syntactic sugar and just auto-generate the > forwarding methods? That is exactly what this proposal does. Why do you feel it is not doing that?
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
