[swift-evolution] [Draft] Mixins
antonyzhilin at gmail.com
Wed Apr 27 05:23:32 CDT 2016
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
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
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
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
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?
2016-04-27 2:50 GMT+03:00 Niall Young <niall at iinet.net.au>:
> 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:
> 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.
> Niall Young
> niall at iinet.net.au
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution