<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPad</div><div><br>On Jan 7, 2016, at 5:41 PM, Kevin Ballard <<a href="mailto:kevin@sb.org">kevin@sb.org</a>> wrote:<br><br></div><blockquote type="cite"><div>
<title></title>
<div>On Thu, Jan 7, 2016, at 03:11 PM, Matthew Johnson wrote:<br></div>
<blockquote type="cite"><div> </div>
<div><blockquote type="cite"><div>On Jan 7, 2016, at 3:31 PM, Kevin Ballard <<a href="mailto:kevin@sb.org">kevin@sb.org</a>> wrote:<br></div>
<div> </div>
<div><div><div>On Thu, Jan 7, 2016, at 07:12 AM, Matthew Johnson wrote:<br></div>
<blockquote type="cite"><div><blockquote type="cite"><div><div><div>As for my concern, it's with the following rule:<br></div>
<div> </div>
<blockquote type="cite">If the initializer body assigns to a var property that received memberwise initialization synthesis report a warning. It is unlikely that overwriting the value provided by the caller is the desired behavior.<br></blockquote><div> </div>
<div>I understand why you put this in there, but this is a warning that cannot be suppressed and will make it impossible to use a memberwise initializer for perfectly legitimate cases where you do in fact want to mutate the property after it's been assigned to.<br></div>
</div>
</div>
</blockquote><div> </div>
<div>For normal initializers I agree with you. However, I think it’s a reasonable for callers to assume that if you expose a property via memberwise initialization the post-initialization value will match the value they provide. This warning is intended to alert you to the fact that you are violating that reasonable assumption.<br></div>
</div>
</blockquote><div> </div>
<div>I think that's a reasonable assumption in many cases, but I don't like the fact that the feature cannot be used at all in the rare case where it actually makes sense to mutate the value.<br></div>
<div> </div>
<blockquote type="cite"><div><div>Do you have an example of where you would want a caller to initialize a property, but then overwrite the value they provide <b>during initialization</b>?<br></div>
</div>
</blockquote><div> </div>
<div>Sure, how about something like a Rect type that always guarantees it's in "standard" form (e.g. no negative sizes):<br></div>
<div> </div>
<div>struct StandardRect {<br></div>
<div> var origin: CGPoint<br></div>
<div> var size: CGSize {<br></div>
<div> didSet {<br></div>
<div> // ensure standardized form here<br></div>
<div> }<br></div>
<div> }<br></div>
<div> </div>
<div> memberwise init(...) {<br></div>
<div> if size.width < 0 {<br></div>
<div> origin.x += size.width<br></div>
<div> size.width = -size.width<br></div>
<div> }<br></div>
<div> if size.height < 0 {<br></div>
<div> origin.y += size.height<br></div>
<div> size.height = -size.height<br></div>
<div> }<br></div>
<div> }<br></div>
<div>}<br></div>
</div>
</div>
</blockquote><div> </div>
<div>This is a good example. Thanks! <br></div>
<div> </div>
<div>I think cases like this will be rare so I still think a warning is a good idea. Something like -Wno-overwrite-memberwise-init would allow it to be suppressed in cases where you actually do intend to do this. Would that satisfy you?<br></div>
</div>
</blockquote><div> </div>
<div>No. It's not appropriate to have the only way to suppress a warning on perfectly legal code to be passing a flag to the swiftc invocation. Especially because we have no precedent yet for even having flags like that.</div></div></blockquote><div><br></div>We will probably have warning flags eventually.<br><blockquote type="cite"><div>
<div> </div>
<div>What's wrong with the suggestion to make the warning behave the same way as dead store warnings (e.g. warn if the property is overwritten without any prior reads)? We already have logic for doing this kind of analysis.<br></div></div></blockquote><div><br></div><div>I missed that suggestion. This is probably sufficient. </div><br><blockquote type="cite"><div>
<div> </div>
<div>-Kevin Ballard</div>
</div></blockquote></body></html>