Repetition forms habit, my nana used to say.
Whether it is writing code or reading it, repetition taps into the procedural memory mechanism of your brain becoming unconscious. Sooner or later, you'll become unaware that "self" is even there. This can be a great thing or the exact opposite of what you want.
There's something very cool about procedural memory: If instead of mechanical, the repetition is fueled by willingness, reasoning and fun, it forms intuition.
The goal, then, is to make complex semantics simple enough that a programmer will be willing (eager even) to reason about complex problems and develop intuition, instead of doing whatever the compiler tells you to do to make your thing work, and end up developing a mechanical habit.
A compiler who has to remind intermediate/veteran Swift programmers of a missing self. or a missing @escaping, or whatever, is a problem in the language. I see this happen all the time. To coworkers, to friends and to my face. And the response to it never is "Phew!", it is "Ugh." (sometimes followed by a random expletive.)
• The optionality of self is what the problem is.
It introduces semantic ambiguity between a complex subject you don't face often (memory management in ARC), and a very simple and familiar one ("reaching a member of an object").
As much as I love Swift, this is kind of a major "wat" to me.
Especially if you're a newcomer trying something inane like updating a label inside an async closure: "Implicit use of self, use self to make closure capture semantics expli" huh? what? wait, there's a fix it button. Whatever, fix it.
This almost guarantees users won't even understand why they should reason about what this is about. It's a nuisance. Even worse, some could end up forming a habit of ignoring the problem till they can feel it's fangs in their butt cheeks.
Two (hopefully) solutions are:
-
Do the exact opposite: Disallow the usage of
self.everywhere it's optional except when it is obligatory. This would make the semantics around it a bit more explicit, without making it repetitive enough as to end up becoming ignored noise. -
Explicit ownership semantics ala Rust. Which is the current direction in which Swift is headed, as far as I can remember from https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md. And the best answer we have to this problem so far, in my arrogant opinion.
Btw, code that is easier to reason and code with bad noise to signal ratio is a dichotomy.