<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I definitely agree there are difficulties with working with nullability and structs. Interesting perspective on how to deal with that. I'd be interested in what others think of your inout type idea.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I think this specific proposal asking for compiler magic to auto-unwrap invisibly and only in very limited cases, as this proposal suggests, ends up breaking a lot more than it fixes. I can only see circumstances of this working with variables in the current scope, as anything like a property could be updated by other methods, threads etc, and the compiler couldn't be certain of state.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I think a language feature like you describe would be a lot more helpful, but I'd love to hear others' views on that.</div><div id="AppleMailSignature"><br>- Rod</div><div><br>On 30 Apr 2016, at 5:22 PM, Haravikk <<a href="mailto:swift-evolution@haravikk.me">swift-evolution@haravikk.me</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On 29 Apr 2016, at 23:28, Rod Brown via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">I agree that it's a pain to have to unwrap after this, but this proposal worries me somewhat.<br class=""><br class="">I don't think we can safely guarantee that the value is non-null outside a very limited subset of cases, and we're breaking the simple, general and reasonable syntax of Swift for a very minor convenience win. <br class=""><br class="">Additionally, this will play out like magic. Suddenly an optional starts dynamically changing its behaviour. I can't see where the compiler begins or ends the assertion of the value's non-null state, and so you have code that, with a little shifting around, begins to fail to even compile, based on something the user cannot see.<br class=""><br class="">I think we have better mechanisms to handle this type of thing, like the if/guard let syntax, and implicitly unwrapped optionals.<br class=""></div></blockquote></div><br class=""><div class="">Actually, thinking about it a bit more I think that the main case where I would want something like this is actually, something more like the following:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if var unwrappedFoo = self.foo {</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>unwrappedFoo.mutate()<span class="Apple-tab-span" style="white-space:pre"> </span>// self.foo is unchanged, we have to do this:</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>self.foo!.mutate()<span class="Apple-tab-span" style="white-space:pre"> </span>// original is changed, but unwrappedFoo is not</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// foo was changed once, not twice</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div class=""><br class=""></div><div class="">Of course classes follow different rules, but it’s a little counter-intuitive for structs, what if we could do something like this:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if inout unwrappedFoo = self.foo {</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>unwrappedFoo.mutate()<span class="Apple-tab-span" style="white-space:pre"> </span>// both are changed</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>self.foo!.mutate()<span class="Apple-tab-span" style="white-space:pre"> </span>// no longer required this</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// foo was changed twice, and both forms are consistent</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div class=""><br class=""></div><div class="">i.e- inout in this case gets us a non-optional reference to the original value, not a copy (or potential copy). In the event that self.foo is changed somewhere else, unwrappedFoo would continue to reference to what it used to be and remain usable, though of course in the above example the call to self.foo! would fail in such a case, but it should no longer be required.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">At least in my experience this is the most common case that I encounter, as I try to use if let or guard let (or var) for safety, but then this doesn’t help when manipulating a struct, so a third option could be useful in such cases.</div></div></blockquote></body></html>