Set-only computed properties

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 self.


My only concern here is that the few times I've run into this error have been accidental, and the error saved me from something broken. It would've been noticed rather quickly, but it is a good check against accidentally implementing something which is almost never intended. But I can see the usefulness.

In a related vein, I have occasionally wished it were possible to make a set-only subscript.


Luckily, it's guaranteed to be caught by the compiler, by the error it would cause at the attempted use of such a non-existent getter

This is an interesting idea pointed out. I found myself several times that in some cases it would be useful to have only setter instead of writing method, but then defined that if I need method to set property that means:
a) my design probably wrong
b) I really need a method here (at least it explicitly says that there are some work performed when you set your value, e.g. original example with hashing, when property says that your value will be stored somewhere).
So I end up with decision that having set-only property is not right solution since it hides some information from the developers and make your code less clear.
Also, I do not see how it could fit into properties design, it would be great to see an example of the syntax how such property defined in the code.

This is not as arbitrary as it might seem.


To elucidate my use-case:

struct Matrix<T> {
  var private(set) elements: [T]


  // Subscript to get an entire row
  subscript(row row: Int) -> ArraySlice<T> {
    get { … }

  // Subscript to set an entire row
  subscript<C: Collection>(row row: Int) -> C
    where C.Element == T
    set { … }

Essentially, I want a subscript where any collection can be assigned to it, but when being read from the result is always one specific type (namely ArraySlice).

So *really* what I want is something that “looks like” one subscript where the setter accepts a more general type than what the getter returns.


Thats seems like a rather straight-forward consequence. I don't think anybody would be confused to learn that chaining the navigation operator calls getters.

Perhaps, but people already get surprised when their property observers are called on parts of the chain that aren't at the end, so I'm willing to say that this is not true. It's also worth noting that this feature is considered confusing enough that it produces a design warning in the primary IDE for at least one language.

1 Like