<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="" applecontenteditable="true"><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 6, 2017, at 11:08, Daniel Duan <<a href="mailto:daniel@duan.org" class="">daniel@duan.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 6, 2017, at 10:58 AM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="" applecontenteditable="true"><div class="">I think I see Alex's point here. Optional chaining is still intended to be a substitute for Objective-C's nil-swallowing, and therefore foo?.bar() should not warn if 'bar' has a discardable result, <i class="">even though</i> there is semantic information about whether the method was actually called. I think that of the three things under consideration here:</div><div class=""><br class=""></div><div class="">1. foo?.bar() should not warn</div><div class="">2. foo.map(baz) should warn</div><div class="">3. Ternaries should be consistent with non-ternaries</div><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">I 100% agree with this analysis.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="" applecontenteditable="true"><div class="">#1 is the most important, at least to me. The Swift 3 change was to sacrifice #2 in favor of #3, which I'm not sure I would have done, but I wouldn't want to sacrifice #1 in favor of #2.</div><div class=""><br class=""></div><div class="">I wouldn't mind the model of the type being '@discardableResult Optional<Void>' or whatever, but I think that's probably more work than anyone wants to sign up for.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I’ll give this a go and report back. *crosses fingers*</div></div></div></div></blockquote><br class=""></div><div>I suspect this will entail making a new sugared type kind and then threading it carefully through the constraint solver (hence why I said it's probably more work than you want to take on).</div><div><br class=""></div><div>Jordan</div><br class=""></body></html>