<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>On Thu, Dec 15, 2016, at 12:51 PM, Michael Ilseman wrote:<br></div>
<blockquote type="cite"><div><br></div>
<div><blockquote type="cite"><div>On Dec 14, 2016, at 6:32 PM, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div>
<div><br></div>
<div><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">I don't think we should ever make it possible to mark an entire class as `dynamic`. This just reintroduces the Obj-C problem, where many properties support KVO, but not all, and there's no indication on the property itself as to whether it supports it.</span></span><br></div>
</blockquote><div><br></div>
<div>I’m not familiar enough with these kinds of bugs. Kevin, do you think the existing behavior aligns with or runs counter to safe-by-default?<br></div>
</div>
</blockquote><div><br></div>
<div>The existing behavior is safe-by-default. You have to opt-in to a property supporting KVO, and the opt-in nature of this means that the property is self-documenting as to whether it supports KVO. Of course, it's possible to write a `dynamic` property that actually doesn't do KVO properly (e.g. because it's a computed property that uses another backing property, and you modify the backing property directly), but since 99.9% of `dynamic` properties are only dynamic in order to support KVO, I have no concerns about someone writing a `dynamic` property that doesn't actually do KVO properly.<br></div>
<div><br></div>
<div>-Kevin Ballard</div>
<div><br></div>
</body>
</html>