Sorry; my point was a bit broader.
It's really great that you gave an explanation! That's definitely an important part of bridging the knowledge gap for complicated features. However, the rest of your message implies that the person to which you're responding doesn't know how KVO works and should learn (by linking to the exact same documentation that they do) and, most importantly, once that happens, they would never accidentally forget to write
dynamic. Additionally, explanations like this are documentation in a different form—with the same major downside: any knowledge is not compiler enforced—and even if the person in this case didn't know how it worked, that only solves the problem for one person.
The key to my point is that humans are fallible: I deeply understand how multiplication and addition work, and yet I've accidentally expanded
x - (y - z) to
x - y - z annoyingly often. Having the rule explained to me again wouldn't fix anything, but having someone, or something, flagging the mistake when I make it would help a lot.
And, the thing that really prompted my response was saying that was no point in complaining. In direct contrast to what you said, there is a point to complaining that doing something in one place (adding a call to
observe, in this case) requires remembering to make changes in other places (adding a
dynamic): half the point of Swift being so much more static than Objective-C is how much more helpful the computer can be in finding when humans violate rules, rather than just relying on humans to read and remember them all. Complaints—such as filing JIRAs, or radars, or even forum posts, as here—help the Swift team/community understand common pitfalls, even if a complaint is driven by a misunderstanding (which it isn't, in this particular case). If we see patterns or notice easy-to-plug holes causing these pitfalls, we can design language/compiler/API features to address them.
I'm very glad that you agree with the later suggestion for adding diagnostics.