Why must I restate the subscript getter for this protocol requirement?

Consider for example:

protocol Table {
  associatedtype Value
  var rowIndices: Range<Int> { get }
  var columnIndices: Range<Int> { get }
  subscript(column: Int, row: Int) -> Value { get }
}

and

protocol MutableTable: Table {
  subscript(column: Int, row: Int) -> Value { set }
}

This will result in the compile time error:

 subscript(column: Int, row: Int) -> Value { set } // ERROR: Subscript with a setter must also have a getter

What is the rationale behind this error?

I mean:
MutableTable: Table
clearly implies that this subscript already has a getter.

1 Like

Considering that Set-only Subscripts are being discussed, it's probably more future-proof to not interpret { set } as being the same as { get set }.

2 Likes

Ignoring the context of the protocols here, yes. But perhaps you mean't that as a suggestion to rethink that error / error message?

Just to be super clear (probably overly so):
My question here is about a protocol (MutableTable) refining another protocol (Table), where the latter requires the getter, ie there already is a getter requirement. So, again, the question is why this getter requirement has to be restated (in MutableTable).

That is, when Swift says (about my specific code above):

ERROR: Subscript with a setter must also have a getter

I say: Yes, sure, but can't you see that the subscript has a getter? It's right there in the code. Can't you see that MutableTable refines Table, and one of the few things Table says/requires is that the subscript has a getter?

You can simplify your example with a property:

protocol P {
    var foo: Int { get }
}

protocol Q: P {
    var foo: Int { set }
}

// error: variable with a setter must also have a getter
//     var foo: Int { set }
//                    ^

This may be due to the fact that P's .foo property may be different from Q's .foo property if you provide a default implementation in a protocol extension, so it should be defined independently.

I still need to understand how variable overloading really works behind the scenes in Swift. This thread may be related:

4 Likes