[Draft] Mixins

Some people opposed to Abstract Classes proposal (including myself) have
said that mixins could solve the problem better.
So I prepaired a proposal draft to add stored properties to protocols. Here
it is:

P.S. I added a `mixin` keyword in the beginning, but we can opt to just
extend protocols, which I mention in "alternatives".

Very interesting alternative!

I think my preferred implementation is to just add these capabilities to protocols directly, as I guess I just don’t see why we need to introduce a separate mixin type. Providing implementation directly within a protocol is definitely something I’d like in general; while extensions can be a nice way to structure complex protocols and types, sometimes simple cases just don’t really need them IMO, so that’d be nice as a general capability, not just for mixins.

···

On 27 Feb 2016, at 09:59, Антон Жилин via swift-evolution <swift-evolution@swift.org> wrote:

Some people opposed to Abstract Classes proposal (including myself) have said that mixins could solve the problem better.
So I prepaired a proposal draft to add stored properties to protocols. Here it is:
mixins-draft.md · GitHub

P.S. I added a `mixin` keyword in the beginning, but we can opt to just extend protocols, which I mention in "alternatives".
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

This is compelling to me.

I haven’t put enough thought into it to make up my mind about it, but a mixin system would solve a problem I’m currently struggling with.

I’ve been working on cleaning up the codebase of my iOS/Mac app, and I’m trying to reduce duplication between the codebases. The problem is, there are things that aren’t easy to completely encapsulate into a separate, universal class — things that have bits and pieces in common, but different overall shape.

Perhaps I should encapsulate them anyway, add a level of indirection, inject dependencies… But a mixin is an abstraction that would allow me to extract common parts in an easier way.

— Radek

···

On 27 Feb 2016, at 10:59, Антон Жилин via swift-evolution <swift-evolution@swift.org> wrote:

Some people opposed to Abstract Classes proposal (including myself) have said that mixins could solve the problem better.
So I prepaired a proposal draft to add stored properties to protocols. Here it is:
mixins-draft.md · GitHub

P.S. I added a `mixin` keyword in the beginning, but we can opt to just extend protocols, which I mention in "alternatives".
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I agree that adding those features to protocols is simpler. I switched the
main suggestion and the alternative.

···

2016-02-27 15:03 GMT+03:00 Haravikk <swift-evolution@haravikk.me>:

Very interesting alternative!

I think my preferred implementation is to just add these capabilities to
protocols directly, as I guess I just don’t see why we need to introduce a
separate mixin type. Providing implementation directly within a protocol is
definitely something I’d like in general; while extensions can be a nice
way to structure complex protocols and types, sometimes simple cases just
don’t really need them IMO, so that’d be nice as a general capability, not
just for mixins.

On 27 Feb 2016, at 09:59, Антон Жилин via swift-evolution < > swift-evolution@swift.org> wrote:

Some people opposed to Abstract Classes proposal (including myself) have
said that mixins could solve the problem better.
So I prepaired a proposal draft to add stored properties to protocols.
Here it is:
mixins-draft.md · GitHub

P.S. I added a `mixin` keyword in the beginning, but we can opt to just
extend protocols, which I mention in "alternatives".
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

You are not alone, discursions like start a long time ago on Swift 1.1 on
the old forum.

I also have here on my desktop some proposals involving storage properties
in protocols.

The idea appears to be simple, but is hard to get a good design.

Properties on Default Protocol Implementations
<http://thread.gmane.org/gmane.comp.lang.swift.evolution/2996&gt;

Some quotes that can help here:

-- Douglas Gregor -- "
Default implementations of functions don’t require per-instance state,
while adding a stored property via a protocol extension does. Let’s step
back to a simpler problem: stored properties in (non-protocol) extensions.

In the existing language, one can only introduce stored properties in the
primary definition of the type. That’s because, when we create an instance
of that type, we need to know how much storage to allocate for that
instance. So, right now, we don’t even allow, e.g.,

struct MyStruct { }
extension MyStruct { var storage: Int = 0 } // error: extensions may not
contain stored properties

class MyClass { }
extension MyClass { var storage: Int = 0 } // error: extensions may not
contain stored properties

because, in the worst case, we don’t know about the storage required for
the “storage” property until after we’ve allocated some instances of
MyStruct or MyClass, and we can’t simply go back and resize those instances
when we learn about the “storage” property. The “worst case” here could
come about with shared libraries: put the MyStruct/MyClass primary
definitions into an app, then put the extensions into a separate shared
library. The app creates some MyStruct and MyClass instances, then loads
the shared library, and now we have a problem: those instances have no
storage for “storage.”

We could relax the requirement to allow extensions in the same module as
the primary definition of that type to introduce stored properties, because
they’re compiled along with the primary type definition anyway. This
doesn’t solve out-of-module extensions, of course.

We could embed a pointer into each instance that points off to the stored
properties for that instance. The pointer would refer to some
lazily-allocated memory on the heap with that extra storage. However, this
would either bloat every data structure by a pointer (including “Int”!) or
have to be opt-in, neither of which are great. I don’t think there is any
reasonable implementation for out-of-module stored properties in extensions
of value types (struct/enum).

For classes, where we have object identity, we could have a side table
containing the stored properties (keyed on the object’s address). This is
how Objective-C’s associated objects work, and it’s a reasonable module for
out-of-module stored properties in extensions of classes.

Getting back to stored properties in protocol extensions, the general
feature isn’t implementable without having some mechanism for out-of-module
stored properties in extensions of structs and enums, so you can limit it
in a few ways:

* Only allow them on class-bound protocols, where there is a reasonable
implementation model

* Allow them as default implementations within a protocol (not an extension
of a protocol!); a type can conform to that protocol either by providing
its own implementation of that property or somewhere where it is reasonable
for the default implementation to inject a stored property into that
context (e.g., on the primary type, within the same module as the primary
type, or on a class).

Either handles the example brought up in the discussion of abstract base
classes.

- Doug
"

-- Chris Lattner -- "

Hi Doug,

Have you considered this similar-but-different approach?

- Allow extensions on classes (only) within the same module/resilience
domain as the class to add stored
properties. This would keep them inline in the instance.
- Allow protocols to have stored property declarations, introducing a
new “protocol with storage”
(PwS) concept.
- Classes can directly conform to a PwS in its definition, or within
an extension inside the same
module/resilience domain.

Just this would give many of the benefits of a full mix-in programming
model. People could define these
protocols, and their local implementation of the type can benefit from
them. It doesn’t support
retroactive mixin’ing, but that is probably a good thing. I’m
assuming that we don’t want to allow
adding state to structs within a resilience domain, just because I
don’t think that is actually a good
thing to add to the programming model (other reasonable people will
surely disagree).

This base model could then be extended:
- Structs could conform to a PwS in their definition, but not an
extension. We could optionally require the
struct to redeclare the properties to improve readability of the
struct, but it wouldn’t be required
from an implementation perspective.
- Classes could conform to a PwS across resilience boundaries, but
wouldn’t get the state: they’d have
to implement the storage requirement with a computed property.
- We could introduce an “associated objects” property behavior that
makes providing the computed
property very straight-forward, using the out of band implementation
approach of ObjC.

The advantages of this approach I see are:

1) implementable, always a bonus.
2) keeps predictable performance. You don’t get out “associated
objects” overhead unexpectedly.
All state is always stored inline.
3) retroactive mixins are possible, but explicit.

The primary downside of this approach is that it introduces yet
another weird protocol variant with
limitations and behaviors, making the model more complicated.

-Chris

"

Some of the challenges I'm having to write my proposal is to find a model
that does not make the language much complex and still bring a direct
benefit.

···

Em sáb, 27 de fev de 2016 às 06:59, Антон Жилин <swift-evolution@swift.org> escreveu:

Some people opposed to Abstract Classes proposal (including myself) have
said that mixins could solve the problem better.
So I prepaired a proposal draft to add stored properties to protocols.
Here it is:
mixins-draft.md · GitHub

P.S. I added a `mixin` keyword in the beginning, but we can opt to just
extend protocols, which I mention in "alternatives".
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

+1 (but *see below*)

Example:

···

My custom Swift notification system currently has two problems that
would be solved by mixins:

1. Anyone conforming to StdEmitterType has to provide “public var
   _listeners = EventStorage()", which is obvious non-ideal (I have an
   Xcode snippet for that).

2. I have EmitterType protocol that defines the publish/subscribe
   contract, and StdEmitterType protocol that provides a standard
   implementation of the publish/subscribe methods using a stored
   _listeners property (provided by the conforming class/struct as
   described in #1). The distinction between EmitterType and
   StdEmitterType is confusing when both are called protocols, because
   StdEmitterType is really a mixin. Calling EmitterType a protocol
   and StdEmitterType a mixin would clear up the confusion.*

*

Because of reason #2, I'm strongly in support of using a separate
keyword.

*I do feel*, however, that maybe this isn't a single problem, but
instead *two orthogonal problems* that could have separate solutions:

1) *Go-style embedding*, where a struct's members become the members of
   its containing struct/class

2) an *“implicit delegate”* facility that allows a struct (you may call
   it a “mixin”) to access the self of its container, and to impose
   requirements on the container (funcs/vars that the container has to
   implement)

#1 is useful without #2 — the logging example doesn't need anything from
#it container, it just wants to add a variable

#2 is useful without #1 — I have other mixin-like examples that benefit
#from being included (a) in multiple copies, and/or (b) non-anonymously
#(with a meaningful name), and/or (c) privately.

*Examples of #2 without #1:*

— I have an activity system in my app that tracks the progress and
completion of a tree of long-running operations (think a Make-like build
process, or an IDE-style code analysis consisting of multiple steps
operating on multiple files). The relevant state management and
notification logic is encapsulated as ProcessorImpl mixin-like class
that tightly binds to its host via an initialization method:

public func initializeWithHost<Host: EmitterType>(host: Host, performs
performMethod: (Host) -> (Request, OperationContext) -> Promise<Void>)

...some classes perform multiple kinds of processing, so they end up
creating multiple ProcessorImpl's; and even for those classes that use
only one instance, it is helpful to give it a name (private let
analysisState = ProcessorImpl()) and to keep it private (it is manually
published via a separate property that has a protocol type)

— my current Delayed class that implements something similar to
performSelector:afterDelay: / cancelPerformSelector in Objective-C, or
to function throttling/unbouncing in JavaScript. It has to be a class,
because it contains mutable state that is modified from within
dispatch_async. Would be great for it to instead be a mixin that would
use the “self” of its container, without creating a separate object.

Thoughts?

One limitation for "mixin" protocols would be that they can't be
retroactively modeled, e.g. by having an extension for that protocol on a
type outside of its file of definition. Allowing this would make the size
of structs and classes unknowable to the compiler as an extension in
another library could change the size of all instances.

That limitation is restrictive enough that having a special type of
protocol and an associated keyword ("mixin") would probably be beneficial.
The compiler could then easily check the intent of the protocol and ensure
that a library doesn't break existing extensions just by adding a stored
property. Only mixin protocols would have this capability.

···

On Sat, Feb 27, 2016 at 9:00 AM, Radosław Pietruszewski < swift-evolution@swift.org> wrote:

This is compelling to me.

I haven’t put enough thought into it to make up my mind about it, but a
mixin system would solve a problem I’m currently struggling with.

I’ve been working on cleaning up the codebase of my iOS/Mac app, and I’m
trying to reduce duplication between the codebases. The problem is, there
are things that aren’t easy to completely encapsulate into a separate,
universal class — things that have bits and pieces in common, but different
overall shape.

Perhaps I should encapsulate them anyway, add a level of indirection,
inject dependencies… But a mixin is an abstraction that would allow me to
extract common parts in an easier way.

— Radek

On 27 Feb 2016, at 10:59, Антон Жилин via swift-evolution < > swift-evolution@swift.org> wrote:

Some people opposed to Abstract Classes proposal (including myself) have
said that mixins could solve the problem better.
So I prepaired a proposal draft to add stored properties to protocols.
Here it is:
mixins-draft.md · GitHub

P.S. I added a `mixin` keyword in the beginning, but we can opt to just
extend protocols, which I mention in "alternatives".
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

Makes sense to me, and mixins are different enough conceptually from most protocols that having a separate keyword (or, more practically, a modifier keyword, like `mixin protocol`) might be desirable anyway.

The fact that protocols already come in two flavors — those that can act as types, and those that have associated types and therefore can only be used as generic constraints — sometimes feels confusing to me. Adding a third kind without any differentiation might not be a good idea.

— Radek

···

On 27 Feb 2016, at 17:17, Trent Nadeau <tanadeau@gmail.com> wrote:

One limitation for "mixin" protocols would be that they can't be retroactively modeled, e.g. by having an extension for that protocol on a type outside of its file of definition. Allowing this would make the size of structs and classes unknowable to the compiler as an extension in another library could change the size of all instances.

That limitation is restrictive enough that having a special type of protocol and an associated keyword ("mixin") would probably be beneficial. The compiler could then easily check the intent of the protocol and ensure that a library doesn't break existing extensions just by adding a stored property. Only mixin protocols would have this capability.

On Sat, Feb 27, 2016 at 9:00 AM, Radosław Pietruszewski <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
This is compelling to me.

I haven’t put enough thought into it to make up my mind about it, but a mixin system would solve a problem I’m currently struggling with.

I’ve been working on cleaning up the codebase of my iOS/Mac app, and I’m trying to reduce duplication between the codebases. The problem is, there are things that aren’t easy to completely encapsulate into a separate, universal class — things that have bits and pieces in common, but different overall shape.

Perhaps I should encapsulate them anyway, add a level of indirection, inject dependencies… But a mixin is an abstraction that would allow me to extract common parts in an easier way.

— Radek

On 27 Feb 2016, at 10:59, Антон Жилин via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Some people opposed to Abstract Classes proposal (including myself) have said that mixins could solve the problem better.
So I prepaired a proposal draft to add stored properties to protocols. Here it is:
mixins-draft.md · GitHub

P.S. I added a `mixin` keyword in the beginning, but we can opt to just extend protocols, which I mention in "alternatives".
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

In my current proposal, stored properties of protocols have no abilities
beyond that of structs. They cannot be declared in extensions, that's
intentional. Could you give an example where such decoupled definition
would be better than multiple mixins, for example?

···

2016-02-27 19:17 GMT+03:00 Trent Nadeau <tanadeau@gmail.com>:

One limitation for "mixin" protocols would be that they can't be
retroactively modeled, e.g. by having an extension for that protocol on a
type outside of its file of definition. Allowing this would make the size
of structs and classes unknowable to the compiler as an extension in
another library could change the size of all instances.

That limitation is restrictive enough that having a special type of
protocol and an associated keyword ("mixin") would probably be beneficial.
The compiler could then easily check the intent of the protocol and ensure
that a library doesn't break existing extensions just by adding a stored
property. Only mixin protocols would have this capability.

On Sat, Feb 27, 2016 at 9:00 AM, Radosław Pietruszewski < > swift-evolution@swift.org> wrote:

This is compelling to me.

I haven’t put enough thought into it to make up my mind about it, but a
mixin system would solve a problem I’m currently struggling with.

I’ve been working on cleaning up the codebase of my iOS/Mac app, and I’m
trying to reduce duplication between the codebases. The problem is, there
are things that aren’t easy to completely encapsulate into a separate,
universal class — things that have bits and pieces in common, but different
overall shape.

Perhaps I should encapsulate them anyway, add a level of indirection,
inject dependencies… But a mixin is an abstraction that would allow me to
extract common parts in an easier way.

— Radek

On 27 Feb 2016, at 10:59, Антон Жилин via swift-evolution < >> swift-evolution@swift.org> wrote:

Some people opposed to Abstract Classes proposal (including myself) have
said that mixins could solve the problem better.
So I prepaired a proposal draft to add stored properties to protocols.
Here it is:
mixins-draft.md · GitHub

P.S. I added a `mixin` keyword in the beginning, but we can opt to just
extend protocols, which I mention in "alternatives".
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

I see many problems with this proposal:

- The proposal doesn't provide a compelling example to change Swift.

- The proposal doesn't provide much detail. It glosses over the general concept.

- Protocols define a statement of conformance, not behavior. Adding instance variables and non-default methods is outside the scope of a protocol.

- However, the proposal does describe something closer to a mix-in. Given my experience with Ruby and mix-ins, I really can't support the notion of mix-ins in Swift. Instance variables defined by a mix-in cause many problems, and hence I don't see this proposal aligned with the direction of Swift.

-Patrick

···

Sent from my iPad Pro

On Feb 27, 2016, at 8:10 AM, Антон Жилин via swift-evolution <swift-evolution@swift.org> wrote:

I agree that adding those features to protocols is simpler. I switched the main suggestion and the alternative.

2016-02-27 15:03 GMT+03:00 Haravikk <swift-evolution@haravikk.me>:

Very interesting alternative!

I think my preferred implementation is to just add these capabilities to protocols directly, as I guess I just don’t see why we need to introduce a separate mixin type. Providing implementation directly within a protocol is definitely something I’d like in general; while extensions can be a nice way to structure complex protocols and types, sometimes simple cases just don’t really need them IMO, so that’d be nice as a general capability, not just for mixins.

On 27 Feb 2016, at 09:59, Антон Жилин via swift-evolution <swift-evolution@swift.org> wrote:

Some people opposed to Abstract Classes proposal (including myself) have said that mixins could solve the problem better.
So I prepaired a proposal draft to add stored properties to protocols. Here it is:
mixins-draft.md · GitHub

P.S. I added a `mixin` keyword in the beginning, but we can opt to just extend protocols, which I mention in "alternatives".
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Thank you, I probably didn't care about the subject at that time, until
abstract classes proposal got serious.
I currently suggest that mixins can only be included directly at type
definition.
I don't think we will lose too much. Extending these possibilities might
follow the proposal *if* it gets accepted.

···

2016-02-28 3:47 GMT+03:00 Wallacy <wallacyf@gmail.com>:

You are not alone, discursions like start a long time ago on Swift 1.1 on
the old forum.

I also have here on my desktop some proposals involving storage properties
in protocols.

The idea appears to be simple, but is hard to get a good design.

Properties on Default Protocol Implementations
<http://thread.gmane.org/gmane.comp.lang.swift.evolution/2996&gt;

Some quotes that can help here:

-- Douglas Gregor -- "
Default implementations of functions don’t require per-instance state,
while adding a stored property via a protocol extension does. Let’s step
back to a simpler problem: stored properties in (non-protocol) extensions.

In the existing language, one can only introduce stored properties in the
primary definition of the type. That’s because, when we create an instance
of that type, we need to know how much storage to allocate for that
instance. So, right now, we don’t even allow, e.g.,

struct MyStruct { }
extension MyStruct { var storage: Int = 0 } // error: extensions may not
contain stored properties

class MyClass { }
extension MyClass { var storage: Int = 0 } // error: extensions may not
contain stored properties

because, in the worst case, we don’t know about the storage required for
the “storage” property until after we’ve allocated some instances of
MyStruct or MyClass, and we can’t simply go back and resize those instances
when we learn about the “storage” property. The “worst case” here could
come about with shared libraries: put the MyStruct/MyClass primary
definitions into an app, then put the extensions into a separate shared
library. The app creates some MyStruct and MyClass instances, then loads
the shared library, and now we have a problem: those instances have no
storage for “storage.”

We could relax the requirement to allow extensions in the same module as
the primary definition of that type to introduce stored properties, because
they’re compiled along with the primary type definition anyway. This
doesn’t solve out-of-module extensions, of course.

We could embed a pointer into each instance that points off to the stored
properties for that instance. The pointer would refer to some
lazily-allocated memory on the heap with that extra storage. However, this
would either bloat every data structure by a pointer (including “Int”!) or
have to be opt-in, neither of which are great. I don’t think there is any
reasonable implementation for out-of-module stored properties in extensions
of value types (struct/enum).

For classes, where we have object identity, we could have a side table
containing the stored properties (keyed on the object’s address). This is
how Objective-C’s associated objects work, and it’s a reasonable module for
out-of-module stored properties in extensions of classes.

Getting back to stored properties in protocol extensions, the general
feature isn’t implementable without having some mechanism for out-of-module
stored properties in extensions of structs and enums, so you can limit it
in a few ways:

* Only allow them on class-bound protocols, where there is a reasonable
implementation model

* Allow them as default implementations within a protocol (not an
extension of a protocol!); a type can conform to that protocol either by
providing its own implementation of that property or somewhere where it is
reasonable for the default implementation to inject a stored property into
that context (e.g., on the primary type, within the same module as the
primary type, or on a class).

Either handles the example brought up in the discussion of abstract base
classes.

- Doug
"

-- Chris Lattner -- "

Hi Doug,

Have you considered this similar-but-different approach?

- Allow extensions on classes (only) within the same module/resilience domain as the class to add stored
properties. This would keep them inline in the instance.
- Allow protocols to have stored property declarations, introducing a new “protocol with storage”
(PwS) concept.
- Classes can directly conform to a PwS in its definition, or within an extension inside the same
module/resilience domain.

Just this would give many of the benefits of a full mix-in programming model. People could define these
protocols, and their local implementation of the type can benefit from them. It doesn’t support
retroactive mixin’ing, but that is probably a good thing. I’m assuming that we don’t want to allow
adding state to structs within a resilience domain, just because I don’t think that is actually a good
thing to add to the programming model (other reasonable people will surely disagree).

This base model could then be extended:
- Structs could conform to a PwS in their definition, but not an extension. We could optionally require the
struct to redeclare the properties to improve readability of the struct, but it wouldn’t be required
from an implementation perspective.
- Classes could conform to a PwS across resilience boundaries, but wouldn’t get the state: they’d have
to implement the storage requirement with a computed property.
- We could introduce an “associated objects” property behavior that makes providing the computed
property very straight-forward, using the out of band implementation approach of ObjC.

The advantages of this approach I see are:

1) implementable, always a bonus.
2) keeps predictable performance. You don’t get out “associated objects” overhead unexpectedly.
All state is always stored inline.
3) retroactive mixins are possible, but explicit.

The primary downside of this approach is that it introduces yet another weird protocol variant with
limitations and behaviors, making the model more complicated.

-Chris

"

Some of the challenges I'm having to write my proposal is to find a model
that does not make the language much complex and still bring a direct
benefit.

Em sáb, 27 de fev de 2016 às 06:59, Антон Жилин <swift-evolution@swift.org> > escreveu:

Some people opposed to Abstract Classes proposal (including myself) have
said that mixins could solve the problem better.
So I prepaired a proposal draft to add stored properties to protocols.
Here it is:
mixins-draft.md · GitHub

P.S. I added a `mixin` keyword in the beginning, but we can opt to just
extend protocols, which I mention in "alternatives".
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Increasingly I am finding that in almost all cases composition provides a better alternative to inheritance. In the case of sharable logic, that logic is better provided as its own complete class with something like the delegate pattern or callbacks if extensibility is required. This encourages small classes with limited responsibility that can be easily/independently tested.

So with that in mind, the problem I see with this proposal is that it introduces syntactical and conceptual complexity to the language - in particular providing a mechanism to resolve cases of the diamond problem, ordering of init/deinit etc is going to make the usage non-trival - without having a substantive benefit outside of what can be achieved more robustly with the existing constructs - such as protocols - the language provides.

For the examples for mixins presented so far, I’d be interested in understanding why they couldn’t be solved with the existing language and design patterns.

-Simon

···

On 1 Mar 2016, at 8:15 PM, Andrey Tarantsov via swift-evolution <swift-evolution@swift.org> wrote:

+1 (but see below)

Example:

My custom Swift notification system currently has two problems that would be solved by mixins:

1. Anyone conforming to StdEmitterType has to provide “public var _listeners = EventStorage()", which is obvious non-ideal (I have an Xcode snippet for that).

2. I have EmitterType protocol that defines the publish/subscribe contract, and StdEmitterType protocol that provides a standard implementation of the publish/subscribe methods using a stored _listeners property (provided by the conforming class/struct as described in #1). The distinction between EmitterType and StdEmitterType is confusing when both are called protocols, because StdEmitterType is really a mixin. Calling EmitterType a protocol and StdEmitterType a mixin would clear up the confusion.

Because of reason #2, I'm strongly in support of using a separate keyword.

I do feel, however, that maybe this isn't a single problem, but instead two orthogonal problems that could have separate solutions:

1) Go-style embedding, where a struct's members become the members of its containing struct/class

2) an “implicit delegate” facility that allows a struct (you may call it a “mixin”) to access the self of its container, and to impose requirements on the container (funcs/vars that the container has to implement)

#1 is useful without #2 — the logging example doesn't need anything from it container, it just wants to add a variable

#2 is useful without #1 — I have other mixin-like examples that benefit from being included (a) in multiple copies, and/or (b) non-anonymously (with a meaningful name), and/or (c) privately.

Examples of #2 without #1:

— I have an activity system in my app that tracks the progress and completion of a tree of long-running operations (think a Make-like build process, or an IDE-style code analysis consisting of multiple steps operating on multiple files). The relevant state management and notification logic is encapsulated as ProcessorImpl mixin-like class that tightly binds to its host via an initialization method:

       public func initializeWithHost<Host: EmitterType>(host: Host, performs performMethod: (Host) -> (Request, OperationContext) -> Promise<Void>)

   ...some classes perform multiple kinds of processing, so they end up creating multiple ProcessorImpl's; and even for those classes that use only one instance, it is helpful to give it a name (private let analysisState = ProcessorImpl()) and to keep it private (it is manually published via a separate property that has a protocol type)

— my current Delayed class that implements something similar to performSelector:afterDelay: / cancelPerformSelector in Objective-C, or to function throttling/unbouncing in JavaScript. It has to be a class, because it contains mutable state that is modified from within dispatch_async. Would be great for it to instead be a mixin that would use the “self” of its container, without creating a separate object.

Thoughts?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

While delegates and callbacks have their place I think inheritance has its place as well. The former are inherently dynamic (pluggable) even if my design might be static and not allow plugging in different functionality at runtime. In addition the delegate needs memory in the base class which is not the case with inheritance.

Regarding testability: if we had real multiple inheritance then testing would be as easy as you can put the logic in its own class instead of a subclass and create the subclass by inheriting from the base class and the logic class. That means you can test the logic class in isolation just like you can do with delegates. Combining functionality like this is called the cake pattern in Scaka.

-Thorsten

···

Am 02.03.2016 um 06:24 schrieb Simon Pilkington via swift-evolution <swift-evolution@swift.org>:

Increasingly I am finding that in almost all cases composition provides a better alternative to inheritance. In the case of sharable logic, that logic is better provided as its own complete class with something like the delegate pattern or callbacks if extensibility is required. This encourages small classes with limited responsibility that can be easily/independently tested.

So with that in mind, the problem I see with this proposal is that it introduces syntactical and conceptual complexity to the language - in particular providing a mechanism to resolve cases of the diamond problem, ordering of init/deinit etc is going to make the usage non-trival - without having a substantive benefit outside of what can be achieved more robustly with the existing constructs - such as protocols - the language provides.

For the examples for mixins presented so far, I’d be interested in understanding why they couldn’t be solved with the existing language and design patterns.

-Simon

On 1 Mar 2016, at 8:15 PM, Andrey Tarantsov via swift-evolution <swift-evolution@swift.org> wrote:

+1 (but see below)

Example:

My custom Swift notification system currently has two problems that would be solved by mixins:

1. Anyone conforming to StdEmitterType has to provide “public var _listeners = EventStorage()", which is obvious non-ideal (I have an Xcode snippet for that).

2. I have EmitterType protocol that defines the publish/subscribe contract, and StdEmitterType protocol that provides a standard implementation of the publish/subscribe methods using a stored _listeners property (provided by the conforming class/struct as described in #1). The distinction between EmitterType and StdEmitterType is confusing when both are called protocols, because StdEmitterType is really a mixin. Calling EmitterType a protocol and StdEmitterType a mixin would clear up the confusion.

Because of reason #2, I'm strongly in support of using a separate keyword.

I do feel, however, that maybe this isn't a single problem, but instead two orthogonal problems that could have separate solutions:

1) Go-style embedding, where a struct's members become the members of its containing struct/class

2) an “implicit delegate” facility that allows a struct (you may call it a “mixin”) to access the self of its container, and to impose requirements on the container (funcs/vars that the container has to implement)

#1 is useful without #2 — the logging example doesn't need anything from it container, it just wants to add a variable

#2 is useful without #1 — I have other mixin-like examples that benefit from being included (a) in multiple copies, and/or (b) non-anonymously (with a meaningful name), and/or (c) privately.

Examples of #2 without #1:

— I have an activity system in my app that tracks the progress and completion of a tree of long-running operations (think a Make-like build process, or an IDE-style code analysis consisting of multiple steps operating on multiple files). The relevant state management and notification logic is encapsulated as ProcessorImpl mixin-like class that tightly binds to its host via an initialization method:

       public func initializeWithHost<Host: EmitterType>(host: Host, performs performMethod: (Host) -> (Request, OperationContext) -> Promise<Void>)

   ...some classes perform multiple kinds of processing, so they end up creating multiple ProcessorImpl's; and even for those classes that use only one instance, it is helpful to give it a name (private let analysisState = ProcessorImpl()) and to keep it private (it is manually published via a separate property that has a protocol type)

— my current Delayed class that implements something similar to performSelector:afterDelay: / cancelPerformSelector in Objective-C, or to function throttling/unbouncing in JavaScript. It has to be a class, because it contains mutable state that is modified from within dispatch_async. Would be great for it to instead be a mixin that would use the “self” of its container, without creating a separate object.

Thoughts?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I don't mean stored properties declared in extensions. I'm talking about
conforming to a "mixin" protocol via an extension in another file. For
example:

// Foo.swift
struct Blah {
    var x : Int
}

// Mixins.swift
protocol MyMixin {
    var y : Double // mixin having a stored property
}

// Bar.swift
extension Blah : MyMixin {} // this changes the size of all instances of
Blah in the program

···

On Sat, Feb 27, 2016 at 11:26 AM, Антон Жилин <antonyzhilin@gmail.com> wrote:

In my current proposal, stored properties of protocols have no abilities
beyond that of structs. They cannot be declared in extensions, that's
intentional. Could you give an example where such decoupled definition
would be better than multiple mixins, for example?

2016-02-27 19:17 GMT+03:00 Trent Nadeau <tanadeau@gmail.com>:

One limitation for "mixin" protocols would be that they can't be
retroactively modeled, e.g. by having an extension for that protocol on a
type outside of its file of definition. Allowing this would make the size
of structs and classes unknowable to the compiler as an extension in
another library could change the size of all instances.

That limitation is restrictive enough that having a special type of
protocol and an associated keyword ("mixin") would probably be beneficial.
The compiler could then easily check the intent of the protocol and ensure
that a library doesn't break existing extensions just by adding a stored
property. Only mixin protocols would have this capability.

On Sat, Feb 27, 2016 at 9:00 AM, Radosław Pietruszewski < >> swift-evolution@swift.org> wrote:

This is compelling to me.

I haven’t put enough thought into it to make up my mind about it, but a
mixin system would solve a problem I’m currently struggling with.

I’ve been working on cleaning up the codebase of my iOS/Mac app, and I’m
trying to reduce duplication between the codebases. The problem is, there
are things that aren’t easy to completely encapsulate into a separate,
universal class — things that have bits and pieces in common, but different
overall shape.

Perhaps I should encapsulate them anyway, add a level of indirection,
inject dependencies… But a mixin is an abstraction that would allow me to
extract common parts in an easier way.

— Radek

On 27 Feb 2016, at 10:59, Антон Жилин via swift-evolution < >>> swift-evolution@swift.org> wrote:

Some people opposed to Abstract Classes proposal (including myself) have
said that mixins could solve the problem better.
So I prepaired a proposal draft to add stored properties to protocols.
Here it is:
mixins-draft.md · GitHub

P.S. I added a `mixin` keyword in the beginning, but we can opt to just
extend protocols, which I mention in "alternatives".
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

--
Trent Nadeau

I think the easier solution is to allow for a default implementation to be
written for a protocol inside of the protocol itself.

···

*___________________________________*

*James⎥Head of Trolls*

*james@supmenow.com <james@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Sat, Feb 27, 2016 at 4:26 PM, Radosław Pietruszewski < swift-evolution@swift.org> wrote:

Makes sense to me, and mixins are different enough conceptually from most
protocols that having a separate keyword (or, more practically, a modifier
keyword, like `mixin protocol`) might be desirable anyway.

The fact that protocols already come in two flavors — those that can act
as types, and those that have associated types and therefore can only be
used as generic constraints — sometimes feels confusing to me. Adding a
third kind without any differentiation might not be a good idea.

— Radek

On 27 Feb 2016, at 17:17, Trent Nadeau <tanadeau@gmail.com> wrote:

One limitation for "mixin" protocols would be that they can't be
retroactively modeled, e.g. by having an extension for that protocol on a
type outside of its file of definition. Allowing this would make the size
of structs and classes unknowable to the compiler as an extension in
another library could change the size of all instances.

That limitation is restrictive enough that having a special type of
protocol and an associated keyword ("mixin") would probably be beneficial.
The compiler could then easily check the intent of the protocol and ensure
that a library doesn't break existing extensions just by adding a stored
property. Only mixin protocols would have this capability.

On Sat, Feb 27, 2016 at 9:00 AM, Radosław Pietruszewski < > swift-evolution@swift.org> wrote:

This is compelling to me.

I haven’t put enough thought into it to make up my mind about it, but a
mixin system would solve a problem I’m currently struggling with.

I’ve been working on cleaning up the codebase of my iOS/Mac app, and I’m
trying to reduce duplication between the codebases. The problem is, there
are things that aren’t easy to completely encapsulate into a separate,
universal class — things that have bits and pieces in common, but different
overall shape.

Perhaps I should encapsulate them anyway, add a level of indirection,
inject dependencies… But a mixin is an abstraction that would allow me to
extract common parts in an easier way.

— Radek

On 27 Feb 2016, at 10:59, Антон Жилин via swift-evolution < >> swift-evolution@swift.org> wrote:

Some people opposed to Abstract Classes proposal (including myself) have
said that mixins could solve the problem better.
So I prepaired a proposal draft to add stored properties to protocols.
Here it is:
mixins-draft.md · GitHub

P.S. I added a `mixin` keyword in the beginning, but we can opt to just
extend protocols, which I mention in "alternatives".
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

James,
I think you misunderstood the proposal. The main goal is to allow protocols
define non-computed properties.
Functions inside protocol body will work different than functions in the
extension, more like functions in classes.

···

2016-02-27 19:27 GMT+03:00 James Campbell <james@supmenow.com>:

I think the easier solution is to allow for a default implementation to be
written for a protocol inside of the protocol itself.

*___________________________________*

*James⎥Head of Trolls*

*james@supmenow.com <james@supmenow.com>⎥supmenow.com
<http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Sat, Feb 27, 2016 at 4:26 PM, Radosław Pietruszewski < > swift-evolution@swift.org> wrote:

Makes sense to me, and mixins are different enough conceptually from most
protocols that having a separate keyword (or, more practically, a modifier
keyword, like `mixin protocol`) might be desirable anyway.

The fact that protocols already come in two flavors — those that can act
as types, and those that have associated types and therefore can only be
used as generic constraints — sometimes feels confusing to me. Adding a
third kind without any differentiation might not be a good idea.

— Radek

On 27 Feb 2016, at 17:17, Trent Nadeau <tanadeau@gmail.com> wrote:

One limitation for "mixin" protocols would be that they can't be
retroactively modeled, e.g. by having an extension for that protocol on a
type outside of its file of definition. Allowing this would make the size
of structs and classes unknowable to the compiler as an extension in
another library could change the size of all instances.

That limitation is restrictive enough that having a special type of
protocol and an associated keyword ("mixin") would probably be beneficial.
The compiler could then easily check the intent of the protocol and ensure
that a library doesn't break existing extensions just by adding a stored
property. Only mixin protocols would have this capability.

On Sat, Feb 27, 2016 at 9:00 AM, Radosław Pietruszewski < >> swift-evolution@swift.org> wrote:

This is compelling to me.

I haven’t put enough thought into it to make up my mind about it, but a
mixin system would solve a problem I’m currently struggling with.

I’ve been working on cleaning up the codebase of my iOS/Mac app, and I’m
trying to reduce duplication between the codebases. The problem is, there
are things that aren’t easy to completely encapsulate into a separate,
universal class — things that have bits and pieces in common, but different
overall shape.

Perhaps I should encapsulate them anyway, add a level of indirection,
inject dependencies… But a mixin is an abstraction that would allow me to
extract common parts in an easier way.

— Radek

On 27 Feb 2016, at 10:59, Антон Жилин via swift-evolution < >>> swift-evolution@swift.org> wrote:

Some people opposed to Abstract Classes proposal (including myself) have
said that mixins could solve the problem better.
So I prepaired a proposal draft to add stored properties to protocols.
Here it is:
mixins-draft.md · GitHub

P.S. I added a `mixin` keyword in the beginning, but we can opt to just
extend protocols, which I mention in "alternatives".
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Ah, I see now. The proposal started with `mixin` keyword being primary and
extending `protocol` in alternatives. Then I swapped then. Maybe I should
swap them again :P

I tend to agree with your argumentation.
Currently proposed methods in protocol extensions act as default methods
(no class inheritance support, if you are aware of that issue), but in
protocol body - as function methods. If we add `mixin protocol`s, then
behaviour of that methods will be consistent.
And do we need associated types (read generics) for mixins?

I also had a proposal for separating protocols and interfaces, but it got
turned down because of proposal for existentials, which I have not heard of
for long. Here it is:
https://github.com/Anton3/swift-evolution/blob/master/proposals/0000-introducing-interfaces.md

If both proposals got accepted, we would have protocols, interfaces and
mixins. Protocols would have associated types, interfaces - dynamism,
mixins - state.

···

2016-02-27 19:32 GMT+03:00 Trent Nadeau <tanadeau@gmail.com>:

I don't mean stored properties declared in extensions. I'm talking about
conforming to a "mixin" protocol via an extension in another file. For
example:

// Foo.swift
struct Blah {
    var x : Int
}

// Mixins.swift
protocol MyMixin {
    var y : Double // mixin having a stored property
}

// Bar.swift
extension Blah : MyMixin {} // this changes the size of all instances of
Blah in the program

On Sat, Feb 27, 2016 at 11:26 AM, Антон Жилин <antonyzhilin@gmail.com> > wrote:

In my current proposal, stored properties of protocols have no abilities
beyond that of structs. They cannot be declared in extensions, that's
intentional. Could you give an example where such decoupled definition
would be better than multiple mixins, for example?

2016-02-27 19:17 GMT+03:00 Trent Nadeau <tanadeau@gmail.com>:

One limitation for "mixin" protocols would be that they can't be
retroactively modeled, e.g. by having an extension for that protocol on a
type outside of its file of definition. Allowing this would make the size
of structs and classes unknowable to the compiler as an extension in
another library could change the size of all instances.

That limitation is restrictive enough that having a special type of
protocol and an associated keyword ("mixin") would probably be beneficial.
The compiler could then easily check the intent of the protocol and ensure
that a library doesn't break existing extensions just by adding a stored
property. Only mixin protocols would have this capability.

On Sat, Feb 27, 2016 at 9:00 AM, Radosław Pietruszewski < >>> swift-evolution@swift.org> wrote:

This is compelling to me.

I haven’t put enough thought into it to make up my mind about it, but a
mixin system would solve a problem I’m currently struggling with.

I’ve been working on cleaning up the codebase of my iOS/Mac app, and
I’m trying to reduce duplication between the codebases. The problem is,
there are things that aren’t easy to completely encapsulate into a
separate, universal class — things that have bits and pieces in common, but
different overall shape.

Perhaps I should encapsulate them anyway, add a level of indirection,
inject dependencies… But a mixin is an abstraction that would allow me to
extract common parts in an easier way.

— Radek

On 27 Feb 2016, at 10:59, Антон Жилин via swift-evolution < >>>> swift-evolution@swift.org> wrote:

Some people opposed to Abstract Classes proposal (including myself)
have said that mixins could solve the problem better.
So I prepaired a proposal draft to add stored properties to protocols.
Here it is:
mixins-draft.md · GitHub

P.S. I added a `mixin` keyword in the beginning, but we can opt to just
extend protocols, which I mention in "alternatives".
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

--
Trent Nadeau

I now have 4 votes "for" separating this new entity from protocols.
Proposal changed.
I tried to solve the aforementioned issues except the last one, which
essentially compares mixins to abstract classes.
More "bug reports" welcome!

···

2016-02-28 16:47 GMT+03:00 Patrick R. Gili <gili.patrick.r@gili-labs.com>:

I see many problems with this proposal:

- The proposal doesn't provide a compelling example to change Swift.

- The proposal doesn't provide much detail. It glosses over the general
concept.

- Protocols define a statement of conformance, not behavior. Adding
instance variables and non-default methods is outside the scope of a
protocol.

- However, the proposal does describe something closer to a mix-in. Given
my experience with Ruby and mix-ins, I really can't support the notion of
mix-ins in Swift. Instance variables defined by a mix-in cause many
problems, and hence I don't see this proposal aligned with the direction of
Swift.

-Patrick

Sent from my iPad Pro

On Feb 27, 2016, at 8:10 AM, Антон Жилин via swift-evolution < > swift-evolution@swift.org> wrote:

I agree that adding those features to protocols is simpler. I switched the
main suggestion and the alternative.

2016-02-27 15:03 GMT+03:00 Haravikk <swift-evolution@haravikk.me>:

Very interesting alternative!

I think my preferred implementation is to just add these capabilities to
protocols directly, as I guess I just don’t see why we need to introduce a
separate mixin type. Providing implementation directly within a protocol is
definitely something I’d like in general; while extensions can be a nice
way to structure complex protocols and types, sometimes simple cases just
don’t really need them IMO, so that’d be nice as a general capability, not
just for mixins.

On 27 Feb 2016, at 09:59, Антон Жилин via swift-evolution < >> swift-evolution@swift.org> wrote:

Some people opposed to Abstract Classes proposal (including myself) have
said that mixins could solve the problem better.
So I prepaired a proposal draft to add stored properties to protocols.
Here it is:
mixins-draft.md · GitHub

P.S. I added a `mixin` keyword in the beginning, but we can opt to just
extend protocols, which I mention in "alternatives".
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

On the subject of ‘subsuming’… it seems with this proposal we now have three approaches to solving the problem of code reuse/specialization: OOP, POP, and Mixin Oriented Programming (MOP). The decision about which approach to use makes the learning curve steeper. Perhaps there is some way to generalize or unify the three approaches, and flatten the learning curve?

In any case, I’m hesitant to add new directions to the language until the current ones have been given the benefit of some more time.

Matt

···

On Feb 28, 2016, at 09:02, Trent Nadeau via swift-evolution <swift-evolution@swift.org> wrote:

In the proposal, I would recommend stressing how this both subsumes abstract classes and allows similar functionality on value types.

In the proposal, I would recommend stressing how this both subsumes
abstract classes and allows similar functionality on value types.

I would also recommend adding a more realistic mixin example such as
logging, where structs and classes want logging functionality but are not
or can't be LoggingObjects. This would show how it gives code reuse without
inheritance and how it would be better than abstract classes.

···

On Sun, Feb 28, 2016 at 11:43 AM, Антон Жилин <swift-evolution@swift.org> wrote:

I now have 4 votes "for" separating this new entity from protocols.
Proposal changed.
I tried to solve the aforementioned issues except the last one, which
essentially compares mixins to abstract classes.
More "bug reports" welcome!

2016-02-28 16:47 GMT+03:00 Patrick R. Gili <gili.patrick.r@gili-labs.com>:

I see many problems with this proposal:

- The proposal doesn't provide a compelling example to change Swift.

- The proposal doesn't provide much detail. It glosses over the general
concept.

- Protocols define a statement of conformance, not behavior. Adding
instance variables and non-default methods is outside the scope of a
protocol.

- However, the proposal does describe something closer to a mix-in. Given
my experience with Ruby and mix-ins, I really can't support the notion of
mix-ins in Swift. Instance variables defined by a mix-in cause many
problems, and hence I don't see this proposal aligned with the direction of
Swift.

-Patrick

Sent from my iPad Pro

On Feb 27, 2016, at 8:10 AM, Антон Жилин via swift-evolution < >> swift-evolution@swift.org> wrote:

I agree that adding those features to protocols is simpler. I switched
the main suggestion and the alternative.

2016-02-27 15:03 GMT+03:00 Haravikk <swift-evolution@haravikk.me>:

Very interesting alternative!

I think my preferred implementation is to just add these capabilities to
protocols directly, as I guess I just don’t see why we need to introduce a
separate mixin type. Providing implementation directly within a protocol is
definitely something I’d like in general; while extensions can be a nice
way to structure complex protocols and types, sometimes simple cases just
don’t really need them IMO, so that’d be nice as a general capability, not
just for mixins.

On 27 Feb 2016, at 09:59, Антон Жилин via swift-evolution < >>> swift-evolution@swift.org> wrote:

Some people opposed to Abstract Classes proposal (including myself) have
said that mixins could solve the problem better.
So I prepaired a proposal draft to add stored properties to protocols.
Here it is:
mixins-draft.md · GitHub

P.S. I added a `mixin` keyword in the beginning, but we can opt to just
extend protocols, which I mention in "alternatives".
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau