A protocol is a statement about the minimum capabilities of a type, and it cannot really restrict the type to having a private setter. From the point of view of someone using the protocol, this is no different than if the protocol declared a { get } requirement, which cannot prevent the conforming type from having a setter, private or public.
I agree with you, but you are describing the current state of protocol in swift. Do you mind if there's any intention to provide such kind of feature in future?
Such features were discussed in topics about abstract classes if I remember correctly. Abstract classes were deferred though. There were also discussions about private protocol requirements.
Simply in a protocol extension mutating func doesn’t work if property is { get } only, this mean u can’t provide a default method your own protocols. @Jumhyn
There can be multiple users of the protocol, or rather multiple users of the eventual implementation of the protocol. One class of user is a pure consumer outside the module. Another has the context and expertise to perform the set and is internal to a module. But users outside the module can at least implement the protocol on their classes. They just hand instances off to the module to perform the expert computation. For example, a grandTotal property. I could write a function that is the source of truth for computing and writing a grand total, so my function accepts any GrandTotalWritable. You build a CartModel for your UI. You need my function to update the values displayed to users. So you need to implement GrandTotalWritable. Now I need to make GrandTotalWritable public, and now any of my internal implementations of GrandTotalWritable can't have internal(set). And so I risk you not using the source of truth function for computing grand total.