Class-constrained protocol extension

[QuinceyMorris]

I'm not sure if this rises to the level of a bug, or if it's just slightly off, or is working as intended. Consider a protocol extension defined like this:

protocol P {
    var isTrue: Bool { get set }
}
extension P where Self: AnyObject {
    func setTrue(_ value: Bool) {
        self.isTrue = value // <- error: "Cannot assign to property: 'self' is immutable"
    }
}

In one sense, this seems right because P is not class-constrained, and the function is not marked mutating. OTOH, it seems wrong, because the function is declared in an extension that "knows" that Self is a reference type.

Now let's try to "fix" this by marking the function as mutating:

extension P where Self: AnyObject {
    mutating func setTrue(_ value: Bool) {
        self.isTrue = value
    }
}
class A: P {
    var isTrue = false
}
let a = A()
a.setTrue(true) // error: "Cannot use mutating member on immutable value: 'a' is a 'let' constant"

The type of a is statically known to the compiler to be class A, which means the error message is at least misleading, but more plausibly flat out wrong.

Is there a bug here somewhere, or is this what should be happening?

(This is the version of Swift in Xcode 10.3.)

[jawbroken]

I don't know about the first part, but the second part is not considered a bug because mutating methods on protocols can replace self.

[QuinceyMorris]

Oh, that's the behavior that lets us have pseudo-factory methods for classes? I never really got that before now.

Still, isn't a little fishy in the case where the extension is "class-constrained" by the where clause? A little bit paradoxical? Worthy of a warning?

[DeFrenZ (Davide De Franceschi)]

There are a few previous threads on the topic:

[Bug?] Reference types and mutating methods

I don't believe this has been addressed, please correct me if I'm wrong. --My Situation-- I've recently been working on an observable collection type. Because each stores ‘subscriptions’ to changes that occur, it made sense to me that this should be a reference type, so subscriptions can't be copied with the values themselves. I have made this class conform to RangeReplaceableCollectionType, providing it with all the standard collection functions. I do the following: let array: ObservedArray<…

Is the 'existential' a value or ref type?

In the given example the compiler complains and want that the method is marked as mutating and the property itself is a var: protocol P { var array: [Int] { get set } } class A: P { var array: [Int] = [] } struct S { let value: AnyObject & P func append() { value.array.append(42) } } My question is now if the "existential" box that the compiler generates for us (also known as any AnyObject & P from this thread) is itself a value or a ref type in Swift?

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

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 wan…

Why can we not mutate mutable members on a reference type?

I stumbled against this wall a few times, previously I simply ignored it, but now it seems like a pointless language limitation. Every object type (right now we only have classes) in Swift is implicitly a subtype of AnyObject, which in fact is like a type alias to the class keyword. That makes any instance that is known to be of type AnyObject a reference type. However when used in a protocol extension the compiler does not allow one mutate mutable members even if Self is guaranteed to be a Any…

(and possibly more...)

[suyashsrijan]

The fact that the class constraint is not inferred with a Self: ClassType constraint is going to be fixed by my PR shortly (see #27057). I don't think it will fix the above issue though (but feel free to file a bug if you think it should be fixed as well).

In the meantime, you need to either mark the setter as nonmutating or move the AnyObject constraint to the protocol directly.

[David_Sweeris]

Would “protocol ClassyP : class, P {} // extend this one” work? I’m not where I can check