While "looks better" is mostly a subjective, aesthetic judgement, there's a point to be made about which form more clearly conveys the semantics of the action that's executed under the hood.
For example, for a regular
get-set property, I would always, in any case, without exceptions, expect the following
var foo = Foo()
foo.bar = 42
assert(foo.bar == 42)
that is, if I
set a value, I expect the same value to be retrieved in the same local scope (like, the very next line).
If more code is present between the
get lines, my expectation wouldn't be valid, unless I'm sure that the code:
- doesn't interact with the
.bar property at all;
- doesn't require
Personally, I derive from this behavior that a line like
foo.bar = 42 will not produce strong side effects (save from stuff like logging, or setting other properties that derive their value form
But I see a
set-only property as something that inherently produces strong side-effects (what's the point, otherwise?), for example sending the set information to a server with a background HTTP request. And in that case, as a reader of the code, I would prefer seeing a function call, instead of an assignment, because a function call communicates that there could be more going on than simple assignment.
Thus, in general I would say that I agree that
button.color = .red
looks better than
but in this particular case, I think the function form "looks better" because it conveys better the fact that something more is going on while calling the function, and this could be reflected better in the function name. For example, in the case of the background HTTP request, I would instead use a name like:
func updateBackendColor(to: Color)
Documentation could be used to clarify the semantics in both cases, but I think it's always better to use more descriptive names first, and then, if the name is not enough, add documentation.
I'm not opposed in principle to the
set-only property idea, but I think it needs very good examples with sufficient generality to justify its addition.