I would think that: Example: A -> (B, C) -> D B.init calls A.super.init(1) C.init calls A.super.init(2) D.init calls B.super.init() and C.super.init()
is an error because there is one A and you have inited it twice. Just like calling super twice is an error currently. On Wednesday, 27 April 2016, Антон Жилин <[email protected]> wrote: > Yes, this is my proposal, and of course, I'm interested :) > > I haven't read into the mentioned papers, but symmetric sum, asymmetric > sum, alias, exclusion and derived operations form a solid basis for > conflict resolution. > Mixins don't have all that tools and try to solve conflicts by being less > strict at composition. > I agree that Swift, as a compiled language, would benefit from the former > more. > > In traits, I like how requirements and definitions are separated using > requirement of protocol conformance. > It follows Uniform Access Principle: noone can require conformance to a > trait. > Are there other benefits? > > I believe there are situations where non-privateness of fields would help, > see my two examples. > This can be overridden by adding a "proxy" computed property. But why is > privateness needed? > > Do traits have initializers? How do they work in diamond pattern? > > Example: A -> (B, C) -> D > B.init calls A.super.init(1) > C.init calls A.super.init(2) > D.init calls B.super.init() and C.super.init() > > Traits are flattened by default. Does it mean that A will be initialized > twice? in what state will A be? > > - Anton > > 2016-04-27 2:50 GMT+03:00 Niall Young <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>>: > >> On Fri, 22 Apr 2016, Антон Жилин wrote: >> >> This feature has been previously discussed. Search for Mixins on >>> swift-evolution archives. >>> >>> I believe it would help to read previous version of the proposal: >>> https://github.com/Anton3/swift-evolution/blob/mixins/proposals/NNNN-mixins.md >>> >> >> Cheers, already read through the thread - I'm more focused on >> implementing Traits, which I think is very similar but slightly different >> to what's been described in the thread to date. >> >> Is this your proposal? I'd love to give you some feedback, throw ideas >> back and forth if you're interested? If we can evolve the concept and >> implementation by Swift 4 that gives me enough time to brush up on C++ and >> start delving into Swift internals to see how best it could be done. >> >> Cheers, >> >> -- >> Niall Young >> [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');> > > > -- -- Howard.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
