# About reassigning self in classes

**URL:** <https://forums.swift.org/t/about-reassigning-self-in-classes/33813>\
**Category:** Using Swift\
**Created:** [February 14, 2020, 8:10am UTC](https://forums.swift.org/t/about-reassigning-self-in-classes/33813 "2020-02-14T08:10:41Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![Jens](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jens/32/12903_2.png) [@Jens](https://forums.swift.org/u/Jens)\
**Post date:** [February 14, 2020, 9:28am UTC](https://forums.swift.org/t/about-reassigning-self-in-classes/33813/3 "2020-02-14T09:28:31Z")

</div>

Thanks for providing those links! I've read them through and they are mostly about the problem as formulated in the [forked thread](https://forums.swift.org/t/extending-a-class-bound-type-to-conform-to-a-protocol-extended-with-mutating-functions/33762), and while they provide answers to the problem from that perspective, they don't quite answer the specific questions of _this_ thread, namely:

Given the program in the OP (which demonstrates that it _is_ possible to reassign self in classes, and that the way it is done is such that it might happen accidentally):

> [@Jens](#):
>
> - Why is it important to prevent reassigning self in classes? _(rhetorical question)_
> - Why is it then **not** prevented to (even accidentally) do so via a protocol's default implementation?

* * *

I've quoted the parts of the linked discussions that comes closest to answering these questions here:

> [@Mutating Function on Class Type (Possible bug?)](https://forums.swift.org/t/mutating-function-on-class-type-possible-bug/15066/6):
>
> Until we have the "this protocol is only for value types" part, we can't do the "treat `mutating` as if it is not there in reference types" part. It's also not obviously a good idea since an immutable class type is pretty much indistinguishable from a value type except for `ObjectIdentifier` (and `===` ).
> 
> (A long time ago @dabrahams and I talked about disallowing classes from conforming to protocols with `mutating` requirements, which is similar. But at this point it'd be massively source-breaking to do so.)

> [@Mutating Function on Class Type (Possible bug?)](https://forums.swift.org/t/mutating-function-on-class-type-possible-bug/15066/7):
>
> One thing I have wondered about related to this issue is why Swift does not allow writing:
> 
> ```swift
> class Foo {
> mutating func bar() {
> self = Foo()
> }
> }
> 
> ```

> [@Mutating Function on Class Type (Possible bug?)](https://forums.swift.org/t/mutating-function-on-class-type-possible-bug/15066/8):
>
> We could allow it, sure. But it would only change _this_ reference, not any other references pointing to the same object, and _not_ having `mutating` doesn't prevent you from changing stored properties (see [Avoiding unbreakable reference cycle with value types and closures?](https://forums.swift.org/t/avoiding-unbreakable-reference-cycle-with-value-types-and-closures/18757/17)). So it's left out of the language to avoid introducing a point of confusion.
> 
> Have you come across a situation where you would have wanted this?

> [@Mutating Function on Class Type (Possible bug?)](https://forums.swift.org/t/mutating-function-on-class-type-possible-bug/15066/9):
>
> No, I just noted it would be a generally consistent and unambiguous extension of the current meaning.

* * *

So what I'm saying is that after reading and understanding the above (and the other parts of the linked discussions) I've yet to see the rationale for the seemingly inconsistent behavior demonstrated by the program in the OP. That is:  
**Why does Swift allow a default implementation of a protocol to reassign self of a class from under our feet** (while actively _preventing_ us from doing it explicitly within the class) **?**

---

_[View the full topic](https://forums.swift.org/t/about-reassigning-self-in-classes/33813)._