<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">First, thank you very much for starting this discussion!<div class=""><br class=""></div><div class="">I have been thinking of an alternate strategy using traits, partially based on <a href="http://web.cecs.pdx.edu/~black/publications/TR_CSE_02-012.pdf" class="">http://web.cecs.pdx.edu/~black/publications/TR_CSE_02-012.pdf</a> .</div><div class=""><br class=""></div><div class="">In my alternate strategy, you would have trait objects which behave similar to value types. They would expose methods/properties, can conform to protocols, and can also require other properties/methods via delegate protocols. When composed by an outer object, the properties/methods and protocol conformance can be either directly addressed or mapped (via some language syntax or via explicit wrapping functions) to the outer object’s usage contract as new properties/methods/protocol conformance. </div><div class=""><br class=""></div><div class="">The trait objects do not hold state, although the delegate protocols they require for usage can provide said state.</div><div class=""><br class=""></div><div class="">Similar to property behaviors, one could make a naive implementation today via generic wrappers. However, this would require duplicated state to provide the delegate protocols where needed, as well as complexity of use and memory duplication when those implementations are backed by value types. Thus, this feature falls into a similar camp of needing compiler support for optimal memory use/performance. While traits behave as if they are separate objects, they should not be treated as such and fall closer into the realm of macros.</div><div class=""><br class=""></div><div class="">You would not include these traits via the inheritance/implementation mechanism - they would not participate in an object’s superclass hierarchy or protocol conformance. Instead they act closer to ‘let’ properties.</div><div class=""><br class=""></div><div class="">Language syntax would be used to selectively map methods, properties, and full protocol conformance from a trait to the externally accessible interface of a composing object. Likewise, you can map properties/methods/protocol conformance of your object to fulfill the delegate protocol requirements of a trait. Unmapped features of a trait are not visible outside an object.</div><div class=""><br class=""></div><div class="">Conflicts between multiple traits just prevent the mapping syntax. However, you should be able to resolve this by writing your own implementations for the conflicting traits on the composing object.</div><div class=""><br class=""></div><div class="">Finally, as indicated before a trait can require multiple delegate protocols, such as how UITableView has both UI behavior and data delegate interfaces. “Mixin” behavior could come from having an object which has a default implementation of that data protocol, and mapping to a property holding an instance of that object within the composing type.</div><div class=""><br class=""></div><div class="">-DW</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Feb 29, 2016, at 11:51 AM, Антон Жилин via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I'm prepairing to create a pull request, so I moved the proposal from Gist to my fork of swift-evolution.<div class="">Link to the proposal new and hopefully final home:</div><div class=""><a href="https://github.com/Anton3/swift-evolution/blob/mixins/proposals/NNNN-mixins.md" class="">https://github.com/Anton3/swift-evolution/blob/mixins/proposals/NNNN-mixins.md</a><br class=""></div><div class=""><br class=""></div><div class="">Should I create a pull request right now or wait a bit?</div><div class=""><br class=""><div class="">Some details need to be discussed:</div><div class=""><br class=""></div><div class="">1. Do mixins need associated types? Would generics be more appropriate to them?</div><div class=""><br class=""></div><div class="">2. `mixin` vs `mixin protocol`. On one hand, `mixin protocol` does not require a keyword.</div><div class="">On the other hand, as stated in a special section, mixins cannot be used everywhere a protocol can. Protocols, mixins, traits, interfaces are all different entities.</div></div><div class=""><br class=""></div><div class="">3. `mixin` vs `trait`. Please read Wiki or any other source and tell what is a better name.</div><div class=""><br class=""></div><div class="">4. Objective-C interfacing. Do we have to require it now? (I doubt so.) Can we allow mixing-in Swift mixins to Objective-C classes?</div><div class=""><br class=""></div><div class="">5. Are you happy with Initializers section?</div><div class=""><br class=""></div><div class="">6. Can motivation examples be improved?</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">2016-02-29 4:07 GMT+03:00 Step C <span dir="ltr" class=""><<a href="mailto:schristopher@bignerdranch.com" target="_blank" class="">schristopher@bignerdranch.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class="">Sorry, I understood "that phrase" to mean what I just stated. <br class=""><br class=""></div><div class=""><div class="h5"><div class=""><br class="">On Feb 28, 2016, at 8:03 PM, Step C <<a href="mailto:schristopher@bignerdranch.com" target="_blank" class="">schristopher@bignerdranch.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">I understood him to mean that abstract classes cannot be used for value types, but it would be natural to want that functionality. Mixins would provide that capability for value types as well as classes.<br class=""></div><div class=""><br class="">On Feb 28, 2016, at 7:41 PM, Trent Nadeau <<a href="mailto:tanadeau@gmail.com" target="_blank" class="">tanadeau@gmail.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">The quoted portion of the proposal below doesn't make any sense to me. Subclasses can't be value types. Do you mean the structs could have similar functionality?<div class=""><br class=""></div><div class=""><span style="color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;line-height:25.6px" class="">Firstly, only classes can inherit from such abstract classes, while it can be easily seen that some subclasses of</span><code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.6px;padding:0.2em 0px;margin:0px;border-radius:3px;color:rgb(51,51,51);background-color:rgba(0,0,0,0.0392157)" class="">CachingSerializable</code><span style="color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;line-height:25.6px" class=""> or </span><code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.6px;padding:0.2em 0px;margin:0px;border-radius:3px;color:rgb(51,51,51);background-color:rgba(0,0,0,0.0392157)" class="">SignalSender</code><span style="color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;line-height:25.6px" class=""> would naturally have value semantics (be structs, in other words).</span><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sun, Feb 28, 2016 at 5:03 PM, Антон Жилин <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="">Link to the proposal: <a href="https://gist.github.com/Anton3/f0550922c1be0fc5447c" target="_blank" class="">https://gist.github.com/Anton3/f0550922c1be0fc5447c</a></div></div><div class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">2016-02-29 0:56 GMT+03:00 Step C <span dir="ltr" class=""><<a href="mailto:schristopher@bignerdranch.com" target="_blank" class="">schristopher@bignerdranch.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It would be helpful if you include the new draft. Or at least a link to it.<br class="">
<span class=""><br class="">
> On Feb 28, 2016, at 3:30 PM, Антон Жилин via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
> I have rewritten almost the whole proposal in the last 10 hours. I encourage everyone interested to reread it and suggest fixes, improvements, as well as new directions for discussion.<br class="">
</span><div class=""><div class="">> _______________________________________________<br class="">
> swift-evolution mailing list<br class="">
> <a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div></div></blockquote></div><br class=""></div>
</div></div><br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="">Trent Nadeau</div>
</div>
</div></blockquote></div></blockquote></div></div></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>