In general the ability to spell an internal requirement on a protocol, including such a thing, would be quite welcome — I frequently hit this during framework development where the framework needs some mutation but others will never be able to use it, hiding these using hidden protocols is somewhat suboptimal as it ends up causing casting or representing these methods using underscored names.
I’d support that, from a personal standpoint at least :)
+1. We have to use var _name: String { get set } or add another internal protocol to workaround it for now.
Workaround 1:
public protocol Animal {
var name: String { get }
func update(_ newName: String)
// DO NOT USE THIS
var _name: String { get set }
}
public extension Animal {
var name: String { _name }
func update(_ newName: String) {
_name = "Animal_\(newName)"
}
}
Workaround 2:
public protocol Animal {
var name: String { get }
mutating func update(_ newName: String)
}
protocol _Animal {
var name: String { get set }
mutating func _update(_ newName: String)
}
extension _Animal {
mutating func _update(_ newName: String) {
name = "Animal_\(newName)"
}
}
public struct Cat: Animal {
public internal(set) var name: String
}
extension Cat: _Animal {
public mutating func update(_ newName: String) {
_update(newName)
}
}
I was doing the same at first. But in real world, Animal will be a public protocol and _Animal is a internal one. The compiler will give an error for the following code.
extension Animal where Self: _Animal {
Of course we can use the same trick as workaround 1 (Just use public protcol _Animal + a comment saying "DO NOT USE THIS externally" or use @_spi mark suggested by @stevapple ).