# Proposal: Intermediate mutation qualifier for protocol functions on reference-types

**URL:** <https://forums.swift.org/t/proposal-intermediate-mutation-qualifier-for-protocol-functions-on-reference-types/401>\
**Category:** Discussion\
**Created:** [December 10, 2015, 10:35pm UTC](https://forums.swift.org/t/proposal-intermediate-mutation-qualifier-for-protocol-functions-on-reference-types/401 "2015-12-10T22:35:30Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![Josh\_Avant](https://avatars.discourse-cdn.com/v4/letter/j/e0b2c6/32.png) [@Josh\_Avant](https://forums.swift.org/u/Josh_Avant)\
**Post date:** [December 10, 2015, 10:35pm UTC](https://forums.swift.org/t/proposal-intermediate-mutation-qualifier-for-protocol-functions-on-reference-types/401/1 "2015-12-10T22:35:30Z")

</div>

Currently, when a reference-type adopts a protocol with a function declared  
as `mutating`, the reference-type's implementation cannot call that  
function internally. This is because the compiler enforces an immutable  
`self` pointer value, and the `mutating` qualifier implies that the  
function implementation may mutate that `self` pointer value.

However, there seems to be a number of fairly reasonable situations where a  
reference-type implementation of these `mutating` functions may only want  
to mutate properties owned by `self`, but not the actual `self` pointer  
value.

Consider this toy example:

```swift
import Foundation

protocol RandomDataTransformable {
    typealias TransformableType
    var data: [TransformableType] { get set }

    mutating func addRandomData()
}

extension RandomDataTransformable where TransformableType == Int {
    mutating func addRandomData() {
        let random = Int(arc4random_uniform(6) + 1)
        data.append(random)
    }
}

/////

// VALID
struct NumberSource_Struct : RandomDataTransformable {
    typealias TransformableType = Int
    var data: [Int] = []

    mutating func addData() {
        addRandomData()
    }
}

// VALID
class NumberSource_ClassDeclaration: NSObject, RandomDataTransformable {
    typealias TransformableType = Int
    var data: [Int] = []
}

var numberSource = NumberSource_ClassDeclaration()
numberSource.addRandomData()

// INVALID
class NumberSource_ClassImplementation: NSObject, RandomDataTransformable {
    typealias TransformableType = Int
    var data: [Int] = []

    func addData() {
        self.addRandomData() // Compiler Error: Cannot use mutating member
on immutable value: 'self' is immutable
    }
}

```

Even despite the fact that the default implementation for `addRandomData`  
does not mutate the `self` pointer value, reference-type implementations  
are unable to call that function internally, since it is marked as  
`mutating`.

Perhaps confusingly, `addRandomData` may be called by externally, by  
objects which own instances of the reference-type (even though, again, it  
may not called internally by the implementation, itself).

Currently, the only solution to allow reference-type implementations to  
call the sample `addRandomData` implementation internally is to qualify the  
whole `RandomDataTransformable` protocol as `class`. The downside here is  
that this takes an otherwise perfectly reference- and struct-compatible  
protocol + extension implementation and restricts it to only apply to  
classes, decreasing overall code reusability.

My proposal would be to introduce an intermediate mutation qualifier that  
applies when protocols are adopted by reference-types. The qualifier would  
specify that the `self` pointer value itself may not be mutated, but  
`self`'s properties may be, as appropriate.

Thoughts, feedback on this?

---

<div class="post-metadata">

**Author:** ![Lily\_Ballard](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lily_ballard/32/5050_2.png) [@Lily\_Ballard](https://forums.swift.org/u/Lily_Ballard)\
**Post date:** [December 11, 2015, 12:03am UTC](https://forums.swift.org/t/proposal-intermediate-mutation-qualifier-for-protocol-functions-on-reference-types/401/2 "2015-12-11T00:03:17Z")

</div>

A couple of miscellaneous points:

\* This problem only occurs when the class inherits a default  
&nbsp;&nbsp;implementation of the method from a protocol extension. If the class  
&nbsp;&nbsp;declares the method itself, then it's no longer a mutating method and  
&nbsp;&nbsp;everything works fine.  
\* The problem exists because mutating functions are allowed to assign  
&nbsp;&nbsp;to self, but methods on class types cannot assign to self, they can  
&nbsp;&nbsp;only mutate the properties of self. This is why we cannot simply  
&nbsp;&nbsp;allow the call to the inherited mutating method, as that method may  
&nbsp;&nbsp;reassign self.  
\* Classes can still call the method, they just have to say  
&nbsp;&nbsp;something like

var this = self this.callMutatingMethod()

Yeah it's a little awkward, but it's not really all that bad for an edge  
case like this.

Another potential workaround requires more work on the protocol side but  
allows implementations to not care about the difference, which is to  
provide a non-mutating variant in an extension restricted by Self:  
AnyObject:

protocol P { var count: Int { get set } mutating func foo()  
-\> String }

extension P { mutating func foo() -\> String { return  
\_mutatingFoo(&self) } }

extension P where Self: AnyObject { func foo() -\> String { var  
this = self return \_mutatingFoo(&this) } }

private func \_mutatingFoo\<T: P\>(inout value: T) -\> String {  
value.count += 1 return "foo" }

Ultimately, I think there's some value in this proposal, but I worry  
about adding a new keyword to handle an edge case like this when there's  
workarounds available. Assuming we do add this feature, I'd suggest  
using something like `mutating(ish)` instead of inventing a brand new  
keyword (there's precedent in `private(set)`).

-Kevin Ballard

> **···**
>
> On Thu, Dec 10, 2015, at 02:35 PM, Josh Avant via swift-evolution wrote:
> 
> > Currently, when a reference-type adopts a protocol with a function  
> > declared as `mutating`, the reference-type's implementation cannot  
> > call that function internally. This is because the compiler enforces  
> > an immutable `self` pointer value, and the `mutating` qualifier  
> > implies that the function implementation may mutate that `self`  
> > pointer value.
> > 
> > However, there seems to be a number of fairly reasonable situations  
> > where a reference-type implementation of these `mutating` functions  
> > may only want to mutate properties owned by `self`, but not the actual  
> > `self` pointer value.
> > 
> > Consider this toy example:
> > 
> > ``` import Foundation
> > 
> > protocol RandomDataTransformable { typealias TransformableType  
> > var data: [TransformableType] { get set }
> > 
> > mutating func addRandomData() }
> > 
> > extension RandomDataTransformable where TransformableType == Int {  
> > mutating func addRandomData() { let random =  
> > Int(arc4random\_uniform(6) + 1) data.append(random) } }
> > 
> > /////
> > 
> > // VALID struct NumberSource\_Struct : RandomDataTransformable {  
> > typealias TransformableType = Int var data: [Int] =
> > 
> > mutating func addData() { addRandomData() } }
> > 
> > // VALID class NumberSource\_ClassDeclaration: NSObject,  
> > RandomDataTransformable { typealias TransformableType = Int var  
> > data: [Int] = }
> > 
> > var numberSource = NumberSource\_ClassDeclaration()  
> > numberSource.addRandomData()
> > 
> > // INVALID class NumberSource\_ClassImplementation: NSObject,  
> > RandomDataTransformable { typealias TransformableType = Int var  
> > data: [Int] =
> > 
> > func addData() { self.addRandomData() // Compiler Error: Cannot  
> > use mutating member on immutable value: 'self' is immutable } } ```
> > 
> > Even despite the fact that the default implementation for  
> > `addRandomData` does not mutate the `self` pointer value, reference-  
> > type implementations are unable to call that function internally,  
> > since it is marked as `mutating`.
> > 
> > Perhaps confusingly, `addRandomData` may be called by externally, by  
> > objects which own instances of the reference-type (even though, again,  
> > it may not called internally by the implementation, itself).
> > 
> > Currently, the only solution to allow reference-type implementations  
> > to call the sample `addRandomData` implementation internally is to  
> > qualify the whole `RandomDataTransformable` protocol as `class`. The  
> > downside here is that this takes an otherwise perfectly reference- and  
> > struct-compatible protocol + extension implementation and restricts it  
> > to only apply to classes, decreasing overall code reusability.
> > 
> > My proposal would be to introduce an intermediate mutation qualifier  
> > that applies when protocols are adopted by reference-types. The  
> > qualifier would specify that the `self` pointer value itself may not  
> > be mutated, but `self`'s properties may be, as appropriate.
> > 
> > Thoughts, feedback on this?
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Slava\_Pestov](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/slava_pestov/32/30204_2.png) [@Slava\_Pestov](https://forums.swift.org/u/Slava_Pestov)\
**Post date:** [December 11, 2015, 7:34pm UTC](https://forums.swift.org/t/proposal-intermediate-mutation-qualifier-for-protocol-functions-on-reference-types/401/3 "2015-12-11T19:34:41Z")

</div>

Hi Josh,

> Currently, when a reference-type adopts a protocol with a function declared as `mutating`, the reference-type's implementation cannot call that function internally. This is because the compiler enforces an immutable `self` pointer value, and the `mutating` qualifier implies that the function implementation may mutate that `self` pointer value.
> 
> However, there seems to be a number of fairly reasonable situations where a reference-type implementation of these `mutating` functions may only want to mutate properties owned by `self`, but not the actual `self` pointer value.

Consider this usage of the code you show below:

var s: RandomDataTransformable = NumberSource\_Struct()  
var ss = s

s.addRandomData()  
// ss.data unchanged

var c: RandomDataTransformable = NumberSource\_ClassDeclaration()  
var cc = c

c.addRandomData()  
// cc.data changed!

It seems it would be difficult to write fully generic code with a protocol that has this behavior, because you cannot rely on value semantics at all. To implement ‘mutating’ class methods correctly, you would in fact have to create a new class instance and re-assign to self every time, to preserve old references, since mutating the old value might break users of the protocol that are written as if the witness was a value type. This seems to defeat the whole purpose of using a reference type in fact.

It seems that if you really know what you’re doing, you can define a one-element struct that conforms to the protocol and contains the reference. This is in fact how Array, Dictionary and Set implement copy-on-write under the hood.

For this reason I’m in favor of going in the opposite direction, and prohibiting classes from conforming to protocols with mutating requirements.

Now that I think about it, setters in protocols have the same issue with confusing behavior from code that expects value semantics. Hmm...

Slava

> **···**
>
> > On Dec 10, 2015, at 2:35 PM, Josh Avant via swift-evolution \<swift-evolution@swift.org\> wrote:
> 
> > Consider this toy example:
> > 
> > ```swift
> > import Foundation
> > 
> > protocol RandomDataTransformable {
> > typealias TransformableType
> > var data: [TransformableType] { get set }
> >    
> > mutating func addRandomData()
> > }
> > 
> > extension RandomDataTransformable where TransformableType == Int {
> > mutating func addRandomData() {
> > let random = Int(arc4random_uniform(6) + 1)
> > data.append(random)
> > }
> > }
> > 
> > /////
> > 
> > // VALID
> > struct NumberSource_Struct : RandomDataTransformable {
> > typealias TransformableType = Int
> > var data: [Int] = []
> >    
> > mutating func addData() {
> > addRandomData()
> > }
> > }
> > 
> > // VALID
> > class NumberSource_ClassDeclaration: NSObject, RandomDataTransformable {
> > typealias TransformableType = Int
> > var data: [Int] = []
> > }
> > 
> > var numberSource = NumberSource_ClassDeclaration()
> > numberSource.addRandomData()
> > 
> > // INVALID
> > class NumberSource_ClassImplementation: NSObject, RandomDataTransformable {
> > typealias TransformableType = Int
> > var data: [Int] = []
> >    
> > func addData() {
> > self.addRandomData() // Compiler Error: Cannot use mutating member on immutable value: 'self' is immutable
> > }
> > }
> > 
> > ```
> > 
> > Even despite the fact that the default implementation for `addRandomData` does not mutate the `self` pointer value, reference-type implementations are unable to call that function internally, since it is marked as `mutating`.
> > 
> > Perhaps confusingly, `addRandomData` may be called by externally, by objects which own instances of the reference-type (even though, again, it may not called internally by the implementation, itself).
> > 
> > Currently, the only solution to allow reference-type implementations to call the sample `addRandomData` implementation internally is to qualify the whole `RandomDataTransformable` protocol as `class`. The downside here is that this takes an otherwise perfectly reference- and struct-compatible protocol + extension implementation and restricts it to only apply to classes, decreasing overall code reusability.
> > 
> > My proposal would be to introduce an intermediate mutation qualifier that applies when protocols are adopted by reference-types. The qualifier would specify that the `self` pointer value itself may not be mutated, but `self`'s properties may be, as appropriate.
> > 
> > Thoughts, feedback on this?  
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![James\_Campbell](https://avatars.discourse-cdn.com/v4/letter/j/f19dbf/32.png) [@James\_Campbell](https://forums.swift.org/u/James_Campbell)\
**Post date:** [December 11, 2015, 7:42pm UTC](https://forums.swift.org/t/proposal-intermediate-mutation-qualifier-for-protocol-functions-on-reference-types/401/4 "2015-12-11T19:42:19Z")

</div>

Hey Swift team can you tell the iTunes Connect team their website is down,  
there is no way to get a hold of them.

> **···**
>
> On Thu, Dec 10, 2015 at 10:35 PM, Josh Avant via swift-evolution \< swift-evolution@swift.org\> wrote:
> 
> > Currently, when a reference-type adopts a protocol with a function  
> > declared as `mutating`, the reference-type's implementation cannot call  
> > that function internally. This is because the compiler enforces an  
> > immutable `self` pointer value, and the `mutating` qualifier implies that  
> > the function implementation may mutate that `self` pointer value.
> > 
> > However, there seems to be a number of fairly reasonable situations where  
> > a reference-type implementation of these `mutating` functions may only want  
> > to mutate properties owned by `self`, but not the actual `self` pointer  
> > value.
> > 
> > Consider this toy example:
> > 
> > ```swift
> > import Foundation
> > 
> > protocol RandomDataTransformable {
> > typealias TransformableType
> > var data: [TransformableType] { get set }
> > 
> > mutating func addRandomData()
> > }
> > 
> > extension RandomDataTransformable where TransformableType == Int {
> > mutating func addRandomData() {
> > let random = Int(arc4random_uniform(6) + 1)
> > data.append(random)
> > }
> > }
> > 
> > /////
> > 
> > // VALID
> > struct NumberSource_Struct : RandomDataTransformable {
> > typealias TransformableType = Int
> > var data: [Int] = []
> > 
> > mutating func addData() {
> > addRandomData()
> > }
> > }
> > 
> > // VALID
> > class NumberSource_ClassDeclaration: NSObject, RandomDataTransformable {
> > typealias TransformableType = Int
> > var data: [Int] = []
> > }
> > 
> > var numberSource = NumberSource_ClassDeclaration()
> > numberSource.addRandomData()
> > 
> > // INVALID
> > class NumberSource_ClassImplementation: NSObject, RandomDataTransformable {
> > typealias TransformableType = Int
> > var data: [Int] = []
> > 
> > func addData() {
> > self.addRandomData() // Compiler Error: Cannot use mutating member
> > on immutable value: 'self' is immutable
> > }
> > }
> > 
> > ```
> > 
> > Even despite the fact that the default implementation for `addRandomData`  
> > does not mutate the `self` pointer value, reference-type implementations  
> > are unable to call that function internally, since it is marked as  
> > `mutating`.
> > 
> > Perhaps confusingly, `addRandomData` may be called by externally, by  
> > objects which own instances of the reference-type (even though, again, it  
> > may not called internally by the implementation, itself).
> > 
> > Currently, the only solution to allow reference-type implementations to  
> > call the sample `addRandomData` implementation internally is to qualify the  
> > whole `RandomDataTransformable` protocol as `class`. The downside here is  
> > that this takes an otherwise perfectly reference- and struct-compatible  
> > protocol + extension implementation and restricts it to only apply to  
> > classes, decreasing overall code reusability.
> > 
> > My proposal would be to introduce an intermediate mutation qualifier that  
> > applies when protocols are adopted by reference-types. The qualifier would  
> > specify that the `self` pointer value itself may not be mutated, but  
> > `self`'s properties may be, as appropriate.
> > 
> > Thoughts, feedback on this?
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> 
> --  
>  Wizard  
> james@supmenow.com  
> +44 7523 279 698

---

<div class="post-metadata">

**Author:** ![Josh\_Avant](https://avatars.discourse-cdn.com/v4/letter/j/e0b2c6/32.png) [@Josh\_Avant](https://forums.swift.org/u/Josh_Avant)\
**Post date:** [December 11, 2015, 5:22pm UTC](https://forums.swift.org/t/proposal-intermediate-mutation-qualifier-for-protocol-functions-on-reference-types/401/5 "2015-12-11T17:22:22Z")

</div>

Thanks, Kevin!

Look forward to any other feedback!

> **···**
>
> On Thursday, December 10, 2015, Kevin Ballard via swift-evolution \< swift-evolution@swift.org\> wrote:
> 
> > A couple of miscellaneous points:
> > 
> > \* This problem only occurs when the class inherits a default  
> > implementation of the method from a protocol extension. If the class  
> > declares the method itself, then it's no longer a mutating method and  
> > everything works fine.  
> > \* The problem exists because mutating functions are allowed to assign to  
> > self, but methods on class types cannot assign to self, they can only  
> > mutate the properties of self. This is why we cannot simply allow the call  
> > to the inherited mutating method, as that method may reassign self.  
> > \* Classes can still call the method, they just have to say something like
> > 
> > var this = self  
> > this.callMutatingMethod()
> > 
> > Yeah it's a little awkward, but it's not really all that bad for an edge  
> > case like this.
> > 
> > Another potential workaround requires more work on the protocol side but  
> > allows implementations to not care about the difference, which is to  
> > provide a non-mutating variant in an extension restricted by Self:  
> > AnyObject:
> > 
> > protocol P {  
> > &nbsp;&nbsp;&nbsp;&nbsp;var count: Int { get set }  
> > &nbsp;&nbsp;&nbsp;&nbsp;mutating func foo() -\> String  
> > }
> > 
> > extension P {  
> > &nbsp;&nbsp;&nbsp;&nbsp;mutating func foo() -\> String {  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return \_mutatingFoo(&self)  
> > &nbsp;&nbsp;&nbsp;&nbsp;}  
> > }
> > 
> > extension P where Self: AnyObject {  
> > &nbsp;&nbsp;&nbsp;&nbsp;func foo() -\> String {  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;var this = self  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return \_mutatingFoo(&this)  
> > &nbsp;&nbsp;&nbsp;&nbsp;}  
> > }
> > 
> > private func \_mutatingFoo\<T: P\>(inout value: T) -\> String {  
> > &nbsp;&nbsp;&nbsp;&nbsp;value.count += 1  
> > &nbsp;&nbsp;&nbsp;&nbsp;return "foo"  
> > }
> > 
> > Ultimately, I think there's some value in this proposal, but I worry about  
> > adding a new keyword to handle an edge case like this when there's  
> > workarounds available. Assuming we do add this feature, I'd suggest using  
> > something like `mutating(ish)` instead of inventing a brand new keyword  
> > (there's precedent in `private(set)`).
> > 
> > -Kevin Ballard
> > 
> > On Thu, Dec 10, 2015, at 02:35 PM, Josh Avant via swift-evolution wrote:
> > 
> > Currently, when a reference-type adopts a protocol with a function  
> > declared as `mutating`, the reference-type's implementation cannot call  
> > that function internally. This is because the compiler enforces an  
> > immutable `self` pointer value, and the `mutating` qualifier implies that  
> > the function implementation may mutate that `self` pointer value.
> > 
> > However, there seems to be a number of fairly reasonable situations where  
> > a reference-type implementation of these `mutating` functions may only want  
> > to mutate properties owned by `self`, but not the actual `self` pointer  
> > value.
> > 
> > Consider this toy example:
> > 
> > ```swift
> > import Foundation
> > 
> > protocol RandomDataTransformable {
> > typealias TransformableType
> > var data: [TransformableType] { get set }
> > 
> > mutating func addRandomData()
> > }
> > 
> > extension RandomDataTransformable where TransformableType == Int {
> > mutating func addRandomData() {
> > let random = Int(arc4random_uniform(6) + 1)
> > data.append(random)
> > }
> > }
> > 
> > /////
> > 
> > // VALID
> > struct NumberSource_Struct : RandomDataTransformable {
> > typealias TransformableType = Int
> > var data: [Int] = []
> > 
> > mutating func addData() {
> > addRandomData()
> > }
> > }
> > 
> > // VALID
> > class NumberSource_ClassDeclaration: NSObject, RandomDataTransformable {
> > typealias TransformableType = Int
> > var data: [Int] = []
> > }
> > 
> > var numberSource = NumberSource_ClassDeclaration()
> > numberSource.addRandomData()
> > 
> > // INVALID
> > class NumberSource_ClassImplementation: NSObject, RandomDataTransformable {
> > typealias TransformableType = Int
> > var data: [Int] = []
> > 
> > func addData() {
> > self.addRandomData() // Compiler Error: Cannot use mutating member
> > on immutable value: 'self' is immutable
> > }
> > }
> > 
> > ```
> > 
> > Even despite the fact that the default implementation for `addRandomData`  
> > does not mutate the `self` pointer value, reference-type implementations  
> > are unable to call that function internally, since it is marked as  
> > `mutating`.
> > 
> > Perhaps confusingly, `addRandomData` may be called by externally, by  
> > objects which own instances of the reference-type (even though, again, it  
> > may not called internally by the implementation, itself).
> > 
> > Currently, the only solution to allow reference-type implementations to  
> > call the sample `addRandomData` implementation internally is to qualify the  
> > whole `RandomDataTransformable` protocol as `class`. The downside here is  
> > that this takes an otherwise perfectly reference- and struct-compatible  
> > protocol + extension implementation and restricts it to only apply to  
> > classes, decreasing overall code reusability.
> > 
> > My proposal would be to introduce an intermediate mutation qualifier that  
> > applies when protocols are adopted by reference-types. The qualifier would  
> > specify that the `self` pointer value itself may not be mutated, but  
> > `self`'s properties may be, as appropriate.
> > 
> > Thoughts, feedback on this?
> > 
> > \*\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\*  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > \<javascript:\_e(%7B%7D,'cvml','swift-evolution@swift.org');\>  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![Chris\_Lattner](https://avatars.discourse-cdn.com/v4/letter/c/bc8723/32.png) [@Chris\_Lattner](https://forums.swift.org/u/Chris_Lattner)\
**Post date:** [December 12, 2015, 2:55am UTC](https://forums.swift.org/t/proposal-intermediate-mutation-qualifier-for-protocol-functions-on-reference-types/401/6 "2015-12-12T02:55:59Z")

</div>

I'm sorry, but this isn't an area that the open source swift team can help with, please check with official apple channels on that.

-Chris

> **···**
>
> > On Dec 11, 2015, at 11:42 AM, James Campbell via swift-evolution \<swift-evolution@swift.org\> wrote:
> > 
> > Hey Swift team can you tell the iTunes Connect team their website is down, there is no way to get a hold of them.
> > 
> > > On Thu, Dec 10, 2015 at 10:35 PM, Josh Avant via swift-evolution \<swift-evolution@swift.org\> wrote:  
> > > Currently, when a reference-type adopts a protocol with a function declared as `mutating`, the reference-type's implementation cannot call that function internally. This is because the compiler enforces an immutable `self` pointer value, and the `mutating` qualifier implies that the function implementation may mutate that `self` pointer value.
> > > 
> > > However, there seems to be a number of fairly reasonable situations where a reference-type implementation of these `mutating` functions may only want to mutate properties owned by `self`, but not the actual `self` pointer value.
> > > 
> > > Consider this toy example:
> > > 
> > > ```swift
> > > import Foundation
> > > 
> > > protocol RandomDataTransformable {
> > > typealias TransformableType
> > > var data: [TransformableType] { get set }
> > >    
> > > mutating func addRandomData()
> > > }
> > > 
> > > extension RandomDataTransformable where TransformableType == Int {
> > > mutating func addRandomData() {
> > > let random = Int(arc4random_uniform(6) + 1)
> > > data.append(random)
> > > }
> > > }
> > > 
> > > /////
> > > 
> > > // VALID
> > > struct NumberSource_Struct : RandomDataTransformable {
> > > typealias TransformableType = Int
> > > var data: [Int] = []
> > >    
> > > mutating func addData() {
> > > addRandomData()
> > > }
> > > }
> > > 
> > > // VALID
> > > class NumberSource_ClassDeclaration: NSObject, RandomDataTransformable {
> > > typealias TransformableType = Int
> > > var data: [Int] = []
> > > }
> > > 
> > > var numberSource = NumberSource_ClassDeclaration()
> > > numberSource.addRandomData()
> > > 
> > > // INVALID
> > > class NumberSource_ClassImplementation: NSObject, RandomDataTransformable {
> > > typealias TransformableType = Int
> > > var data: [Int] = []
> > >    
> > > func addData() {
> > > self.addRandomData() // Compiler Error: Cannot use mutating member on immutable value: 'self' is immutable
> > > }
> > > }
> > > 
> > > ```
> > > 
> > > Even despite the fact that the default implementation for `addRandomData` does not mutate the `self` pointer value, reference-type implementations are unable to call that function internally, since it is marked as `mutating`.
> > > 
> > > Perhaps confusingly, `addRandomData` may be called by externally, by objects which own instances of the reference-type (even though, again, it may not called internally by the implementation, itself).
> > > 
> > > Currently, the only solution to allow reference-type implementations to call the sample `addRandomData` implementation internally is to qualify the whole `RandomDataTransformable` protocol as `class`. The downside here is that this takes an otherwise perfectly reference- and struct-compatible protocol + extension implementation and restricts it to only apply to classes, decreasing overall code reusability.
> > > 
> > > My proposal would be to introduce an intermediate mutation qualifier that applies when protocols are adopted by reference-types. The qualifier would specify that the `self` pointer value itself may not be mutated, but `self`'s properties may be, as appropriate.
> > > 
> > > Thoughts, feedback on this?
> > > 
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > swift-evolution mailing list  
> > > swift-evolution@swift.org  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > --  
> >  Wizard  
> > james@supmenow.com  
> > +44 7523 279 698
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![gwendal.roue](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/gwendal.roue/32/13992_2.png) [@gwendal.roue](https://forums.swift.org/u/gwendal.roue)\
**Post date:** [December 11, 2015, 7:43pm UTC](https://forums.swift.org/t/proposal-intermediate-mutation-qualifier-for-protocol-functions-on-reference-types/401/7 "2015-12-11T19:43:48Z")

</div>

This would go too far.

It’s common to write a protocol with mutating methods just because the protocol designer expects that some adopting structs may want to mutate in their implementation. And in this case the goal of the protocol designer is certainly not to limit the protocol adoption to structs.

Here is an example:

&nbsp;&nbsp;protocol DatabaseFetchable {  
&nbsp;&nbsp;&nbsp;&nbsp;mutating func awakeFromFetch()  
&nbsp;&nbsp;}  
&nbsp;&nbsp;extension DatabaseFetchable {  
&nbsp;&nbsp;&nbsp;&nbsp;func fetch() -\> Self {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;var value = /\* details omitted \*/  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;value.awakeFromFetch()  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return value  
&nbsp;&nbsp;&nbsp;&nbsp;}  
&nbsp;&nbsp;}

The protocol does not care at all if awakeFromFetch mutates or not. But the protocol designer does: if the awakeFromFetch method were not declared mutating, many structs could simply not adopt it.

Gwendal Roué

> **···**
>
> > Le 11 déc. 2015 à 20:34, Slava Pestov via swift-evolution \<swift-evolution@swift.org\> a écrit :
> > 
> > For this reason I’m in favor of going in the opposite direction, and prohibiting classes from conforming to protocols with mutating requirements.

---

<div class="post-metadata">

**Author:** ![Slava\_Pestov](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/slava_pestov/32/30204_2.png) [@Slava\_Pestov](https://forums.swift.org/u/Slava_Pestov)\
**Post date:** [December 11, 2015, 7:44pm UTC](https://forums.swift.org/t/proposal-intermediate-mutation-qualifier-for-protocol-functions-on-reference-types/401/8 "2015-12-11T19:44:43Z")

</div>

I guess the question is, does it even make sense to write a protocol that can be adopted by both a struct and a class, if the protocol has mutating members?

Slava

> **···**
>
> > On Dec 11, 2015, at 11:43 AM, Gwendal Roué \<gwendal.roue@gmail.com\> wrote:
> > 
> > > Le 11 déc. 2015 à 20:34, Slava Pestov via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> a écrit :
> > > 
> > > For this reason I’m in favor of going in the opposite direction, and prohibiting classes from conforming to protocols with mutating requirements.
> > 
> > This would go too far.
> > 
> > It’s common to write a protocol with mutating methods just because the protocol designer expects that some adopting structs may want to mutate in their implementation. And in this case the goal of the protocol designer is certainly not to limit the protocol adoption to structs.
> > 
> > Here is an example:
> > 
> > &nbsp;&nbsp;protocol DatabaseFetchable {  
> > &nbsp;&nbsp;&nbsp;&nbsp;mutating func awakeFromFetch()  
> > &nbsp;&nbsp;}  
> > &nbsp;&nbsp;extension DatabaseFetchable {  
> > &nbsp;&nbsp;&nbsp;&nbsp;func fetch() -\> Self {  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;var value = /\* details omitted \*/  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;value.awakeFromFetch()  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return value  
> > &nbsp;&nbsp;&nbsp;&nbsp;}  
> > &nbsp;&nbsp;}
> > 
> > The protocol does not care at all if awakeFromFetch mutates or not. But the protocol designer does: if the awakeFromFetch method were not declared mutating, many structs could simply not adopt it.
> > 
> > Gwendal Roué

---

<div class="post-metadata">

**Author:** ![Josh\_Avant](https://avatars.discourse-cdn.com/v4/letter/j/e0b2c6/32.png) [@Josh\_Avant](https://forums.swift.org/u/Josh_Avant)\
**Post date:** [December 11, 2015, 10:14pm UTC](https://forums.swift.org/t/proposal-intermediate-mutation-qualifier-for-protocol-functions-on-reference-types/401/9 "2015-12-11T22:14:33Z")

</div>

It seems it would be difficult to write fully generic code with a protocol  
that has this behavior, because you cannot rely on value semantics at all.  
To implement ‘mutating’ class methods correctly, you would in fact have to  
create a new class instance and re-assign to self every time, to preserve  
old references, since mutating the old value might break users of the  
protocol that are written as if the witness was a value type. This seems to  
defeat the whole purpose of using a reference type in fact.

Agreed. That description even seems to sound like a rehashing of the same  
problem, but from a more strictly value-centric approach.

The 'one-element struct' solution isn't what I was looking for, here. I  
wasn't trying to achieve copy-on-write of a whole object structure, but  
instead writing more fully generic code. Also, not having to use an awkward  
workaround (i.e. the var this = self; this.mutatingMethod()).

I guess the question is, does it even make sense to write a protocol that  
can be adopted by both a struct and a class, if the protocol has mutating  
members?

I think so. But I think part of the problem is that protocol members are  
currently interpreted in terms of value semantics, but protocols are, of  
course, widely used in reference semantics, too.

To me, it feels like we're lacking a degree of fidelity. That's why my  
initial proposition was a `mutating`-ish operator that applies specifically  
to this scenario, and provides a more nuanced bridging to reference  
semantics (feels vaguely similar in nature to unowned vs. weak modifiers).

> **···**
>
> On Fri, Dec 11, 2015 at 11:44 AM, Slava Pestov \<spestov@apple.com\> wrote:
> 
> > On Dec 11, 2015, at 11:43 AM, Gwendal Roué \<gwendal.roue@gmail.com\> wrote:
> > 
> > Le 11 déc. 2015 à 20:34, Slava Pestov via swift-evolution \< \> swift-evolution@swift.org\> a écrit :
> > 
> > For this reason I’m in favor of going in the opposite direction, and  
> > prohibiting classes from conforming to protocols with mutating requirements.
> > 
> > This would go too far.
> > 
> > It’s common to write a protocol with mutating methods just because the  
> > protocol designer expects that some adopting structs may want to mutate in  
> > their implementation. And in this case the goal of the protocol designer is  
> > certainly not to limit the protocol adoption to structs.
> > 
> > Here is an example:
> > 
> > protocol DatabaseFetchable {  
> > &nbsp;&nbsp;mutating func awakeFromFetch()  
> > }  
> > extension DatabaseFetchable {  
> > &nbsp;&nbsp;func fetch() -\> Self {  
> > &nbsp;&nbsp;&nbsp;&nbsp;var value = /\* details omitted \*/  
> > &nbsp;&nbsp;&nbsp;&nbsp;value.awakeFromFetch()  
> > &nbsp;&nbsp;&nbsp;&nbsp;return value  
> > &nbsp;&nbsp;}  
> > }
> > 
> > The protocol does not care at all if awakeFromFetch mutates or not. But  
> > the protocol designer does: if the awakeFromFetch method were not declared  
> > mutating, many structs could simply not adopt it.
> > 
> > Gwendal Roué
> > 
> > I guess the question is, does it even make sense to write a protocol that  
> > can be adopted by both a struct and a class, if the protocol has mutating  
> > members?
> > 
> > Slava

---

<div class="post-metadata">

**Author:** ![gwendal.roue](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/gwendal.roue/32/13992_2.png) [@gwendal.roue](https://forums.swift.org/u/gwendal.roue)\
**Post date:** [December 11, 2015, 5:44pm UTC](https://forums.swift.org/t/proposal-intermediate-mutation-qualifier-for-protocol-functions-on-reference-types/401/10 "2015-12-11T17:44:39Z")

</div>

I did report this problem as [[SR-142] mutating function in protocol extension erroneously requires `var` declaration of class variables · Issue #42764 · apple/swift · GitHub](https://bugs.swift.org/browse/SR-142) a couple of days ago.

Greg Titus replied:

> Looked into this briefly, and it's a lot harder than just changing the error checking, since m() has an implicit `inout P` first argument. Probably the solution is an automatic version of Gwendal's workaround: declaring a hidden `var p: P = c` and calling the method on p.

Gwendal Roué

> **···**
>
> > Le 11 déc. 2015 à 18:22, Josh Avant via swift-evolution \<swift-evolution@swift.org\> a écrit :
> > 
> > Thanks, Kevin!
> > 
> > Look forward to any other feedback!
> > 
> > On Thursday, December 10, 2015, Kevin Ballard via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> wrote:  
> > A couple of miscellaneous points:
> > 
> > \* This problem only occurs when the class inherits a default implementation of the method from a protocol extension. If the class declares the method itself, then it's no longer a mutating method and everything works fine.  
> > \* The problem exists because mutating functions are allowed to assign to self, but methods on class types cannot assign to self, they can only mutate the properties of self. This is why we cannot simply allow the call to the inherited mutating method, as that method may reassign self.  
> > \* Classes can still call the method, they just have to say something like
> > 
> > var this = self  
> > this.callMutatingMethod()
> > 
> > Yeah it's a little awkward, but it's not really all that bad for an edge case like this.
> > 
> > Another potential workaround requires more work on the protocol side but allows implementations to not care about the difference, which is to provide a non-mutating variant in an extension restricted by Self: AnyObject:
> > 
> > protocol P {  
> > &nbsp;&nbsp;&nbsp;&nbsp;var count: Int { get set }  
> > &nbsp;&nbsp;&nbsp;&nbsp;mutating func foo() -\> String  
> > }
> > 
> > extension P {  
> > &nbsp;&nbsp;&nbsp;&nbsp;mutating func foo() -\> String {  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return \_mutatingFoo(&self)  
> > &nbsp;&nbsp;&nbsp;&nbsp;}  
> > }
> > 
> > extension P where Self: AnyObject {  
> > &nbsp;&nbsp;&nbsp;&nbsp;func foo() -\> String {  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;var this = self  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return \_mutatingFoo(&this)  
> > &nbsp;&nbsp;&nbsp;&nbsp;}  
> > }
> > 
> > private func \_mutatingFoo\<T: P\>(inout value: T) -\> String {  
> > &nbsp;&nbsp;&nbsp;&nbsp;value.count += 1  
> > &nbsp;&nbsp;&nbsp;&nbsp;return "foo"  
> > }
> > 
> > Ultimately, I think there's some value in this proposal, but I worry about adding a new keyword to handle an edge case like this when there's workarounds available. Assuming we do add this feature, I'd suggest using something like `mutating(ish)` instead of inventing a brand new keyword (there's precedent in `private(set)`).
> > 
> > -Kevin Ballard
> > 
> > On Thu, Dec 10, 2015, at 02:35 PM, Josh Avant via swift-evolution wrote:
> > 
> > > Currently, when a reference-type adopts a protocol with a function declared as `mutating`, the reference-type's implementation cannot call that function internally. This is because the compiler enforces an immutable `self` pointer value, and the `mutating` qualifier implies that the function implementation may mutate that `self` pointer value.
> > > 
> > > However, there seems to be a number of fairly reasonable situations where a reference-type implementation of these `mutating` functions may only want to mutate properties owned by `self`, but not the actual `self` pointer value.
> > > 
> > > Consider this toy example:
> > > 
> > > ```swift
> > > import Foundation
> > > 
> > > protocol RandomDataTransformable {
> > > typealias TransformableType
> > > var data: [TransformableType] { get set }
> > > 
> > > mutating func addRandomData()
> > > }
> > > 
> > > extension RandomDataTransformable where TransformableType == Int {
> > > mutating func addRandomData() {
> > > let random = Int(arc4random_uniform(6) + 1)
> > > data.append(random)
> > > }
> > > }
> > > 
> > > /////
> > > 
> > > // VALID
> > > struct NumberSource_Struct : RandomDataTransformable {
> > > typealias TransformableType = Int
> > > var data: [Int] = []
> > > 
> > > mutating func addData() {
> > > addRandomData()
> > > }
> > > }
> > > 
> > > // VALID
> > > class NumberSource_ClassDeclaration: NSObject, RandomDataTransformable {
> > > typealias TransformableType = Int
> > > var data: [Int] = []
> > > }
> > > 
> > > var numberSource = NumberSource_ClassDeclaration()
> > > numberSource.addRandomData()
> > > 
> > > // INVALID
> > > class NumberSource_ClassImplementation: NSObject, RandomDataTransformable {
> > > typealias TransformableType = Int
> > > var data: [Int] = []
> > > 
> > > func addData() {
> > > self.addRandomData() // Compiler Error: Cannot use mutating member on immutable value: 'self' is immutable
> > > }
> > > }
> > > 
> > > ```
> > > 
> > > Even despite the fact that the default implementation for `addRandomData` does not mutate the `self` pointer value, reference-type implementations are unable to call that function internally, since it is marked as `mutating`.
> > > 
> > > Perhaps confusingly, `addRandomData` may be called by externally, by objects which own instances of the reference-type (even though, again, it may not called internally by the implementation, itself).
> > > 
> > > Currently, the only solution to allow reference-type implementations to call the sample `addRandomData` implementation internally is to qualify the whole `RandomDataTransformable` protocol as `class`. The downside here is that this takes an otherwise perfectly reference- and struct-compatible protocol + extension implementation and restricts it to only apply to classes, decreasing overall code reusability.
> > > 
> > > My proposal would be to introduce an intermediate mutation qualifier that applies when protocols are adopted by reference-types. The qualifier would specify that the `self` pointer value itself may not be mutated, but `self`'s properties may be, as appropriate.
> > > 
> > > Thoughts, feedback on this?
> > > 
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > swift-evolution mailing list  
> > > swift-evolution@swift.org \<javascript:\_e(%7B%7D,'cvml','swift-evolution@swift.org');\>  
> > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-evolution mailing list  
> > swift-evolution@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)

---

<div class="post-metadata">

**Author:** ![gwendal.roue](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/gwendal.roue/32/13992_2.png) [@gwendal.roue](https://forums.swift.org/u/gwendal.roue)\
**Post date:** [December 11, 2015, 7:48pm UTC](https://forums.swift.org/t/proposal-intermediate-mutation-qualifier-for-protocol-functions-on-reference-types/401/11 "2015-12-11T19:48:03Z")

</div>

I just gave you an answer above: when the protocol designer does not care whether the protocol should be adopted by a struct or a class. Who knows? Maybe the user will adopt the protocol in an extension of an existing type, which happens to already be a struct or a class? Maybe the user will want to adopt the protocol in the base class of a class hierarchy? Who knows?

Gwendal Roué

> **···**
>
> > Le 11 déc. 2015 à 20:44, Slava Pestov \<spestov@apple.com\> a écrit :
> > 
> > > On Dec 11, 2015, at 11:43 AM, Gwendal Roué \<gwendal.roue@gmail.com \<mailto:gwendal.roue@gmail.com\>\> wrote:
> > > 
> > > > Le 11 déc. 2015 à 20:34, Slava Pestov via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> a écrit :
> > > > 
> > > > For this reason I’m in favor of going in the opposite direction, and prohibiting classes from conforming to protocols with mutating requirements.
> > > 
> > > This would go too far.
> > > 
> > > It’s common to write a protocol with mutating methods just because the protocol designer expects that some adopting structs may want to mutate in their implementation. And in this case the goal of the protocol designer is certainly not to limit the protocol adoption to structs.
> > > 
> > > Here is an example:
> > > 
> > > &nbsp;&nbsp;protocol DatabaseFetchable {  
> > > &nbsp;&nbsp;&nbsp;&nbsp;mutating func awakeFromFetch()  
> > > &nbsp;&nbsp;}  
> > > &nbsp;&nbsp;extension DatabaseFetchable {  
> > > &nbsp;&nbsp;&nbsp;&nbsp;func fetch() -\> Self {  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;var value = /\* details omitted \*/  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;value.awakeFromFetch()  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return value  
> > > &nbsp;&nbsp;&nbsp;&nbsp;}  
> > > &nbsp;&nbsp;}
> > > 
> > > The protocol does not care at all if awakeFromFetch mutates or not. But the protocol designer does: if the awakeFromFetch method were not declared mutating, many structs could simply not adopt it.
> > > 
> > > Gwendal Roué
> > 
> > I guess the question is, does it even make sense to write a protocol that can be adopted by both a struct and a class, if the protocol has mutating members?

---

<div class="post-metadata">

**Author:** ![gwendal.roue](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/gwendal.roue/32/13992_2.png) [@gwendal.roue](https://forums.swift.org/u/gwendal.roue)\
**Post date:** [December 11, 2015, 7:56pm UTC](https://forums.swift.org/t/proposal-intermediate-mutation-qualifier-for-protocol-functions-on-reference-types/401/12 "2015-12-11T19:56:51Z")

</div>

BTW, we have three workarounds to the initial problem so far, using the current state of Swift:

1. the one by Kevin Ballard below in the thread (the best one)  
2. my first work around at [[SR-142] mutating function in protocol extension erroneously requires `var` declaration of class variables · Issue #42764 · apple/swift · GitHub](https://bugs.swift.org/browse/SR-142)  
3. declare a non-mutating protocol that inherits from the mutating one, and let classes adopt the non-mutating one, as in:

&nbsp;&nbsp;protocol MutableP {  
&nbsp;&nbsp;&nbsp;&nbsp;mutating func f()  
&nbsp;&nbsp;}  
&nbsp;&nbsp;protocol P : MutableP {  
&nbsp;&nbsp;&nbsp;&nbsp;func f()  
&nbsp;&nbsp;}

The last workaround is a different in that it leaves room for structs that decide not to mutate in their implementation of the protocol.

You have an example of this approach at [GitHub - groue/GRDB.swift: A toolkit for SQLite databases, with a focus on application development](https://github.com/groue/GRDB.swift#databasepersistable-protocol)

Gwendal Roué

> **···**
>
> > Le 11 déc. 2015 à 20:44, Slava Pestov \<spestov@apple.com\> a écrit :
> > 
> > > On Dec 11, 2015, at 11:43 AM, Gwendal Roué \<gwendal.roue@gmail.com \<mailto:gwendal.roue@gmail.com\>\> wrote:
> > > 
> > > > Le 11 déc. 2015 à 20:34, Slava Pestov via swift-evolution \<swift-evolution@swift.org \<mailto:swift-evolution@swift.org\>\> a écrit :
> > > > 
> > > > For this reason I’m in favor of going in the opposite direction, and prohibiting classes from conforming to protocols with mutating requirements.
> > > 
> > > This would go too far.
> > > 
> > > It’s common to write a protocol with mutating methods just because the protocol designer expects that some adopting structs may want to mutate in their implementation. And in this case the goal of the protocol designer is certainly not to limit the protocol adoption to structs.
> > > 
> > > Here is an example:
> > > 
> > > &nbsp;&nbsp;protocol DatabaseFetchable {  
> > > &nbsp;&nbsp;&nbsp;&nbsp;mutating func awakeFromFetch()  
> > > &nbsp;&nbsp;}  
> > > &nbsp;&nbsp;extension DatabaseFetchable {  
> > > &nbsp;&nbsp;&nbsp;&nbsp;func fetch() -\> Self {  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;var value = /\* details omitted \*/  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;value.awakeFromFetch()  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return value  
> > > &nbsp;&nbsp;&nbsp;&nbsp;}  
> > > &nbsp;&nbsp;}
> > > 
> > > The protocol does not care at all if awakeFromFetch mutates or not. But the protocol designer does: if the awakeFromFetch method were not declared mutating, many structs could simply not adopt it.
> > > 
> > > Gwendal Roué
> > 
> > I guess the question is, does it even make sense to write a protocol that can be adopted by both a struct and a class, if the protocol has mutating members?
> > 
> > Slava