There are some cases in which it's useful to have computed properties that can only be set, but never read. Currently, you're forced to use methods for this. Examples:
- ANSI terminal escape sequences can be set (for colour, text style, clearing lines/screens, etc.)
- A lot of robotic control systems have no feedback mechanisms. You set a desired value, and hope that the hardware is doing a decent-enough job of reflecting that value in the real world. You could remember the last value that was set, and return that whenever a getter is called, but it's more deceiving than useful.
- Setting a value that's immediately hashed and never persisted. It's practically impossible to get back the original value.
Admittedly, such situations are rare, but they can benefit from the ability to write set-only properties, at practically no cost.
Being forced to write methods isn't the end of the world, but I find
terminal.color = .red to be preferable to
terminal.setColor(.red), but perhaps that's just personal taste.
The restriction that computed properties must have getters, and that those getters must have a higher visibility levels than their counterpart setters, both seem like arbitrary restrictions that can harmlessly be lifted.
Fun fact: Swift actually has a
nonmutating keyword, that I suspect is not well known in the community. It allows a setter to be called on a
let value, so long as the setter doesn't mutate
self. This is precedent for the idea that getters/setters don't necessarily have to be coupled to only changing the state of